How to Convert Unix Timestamps to Dates

Unix time counts elapsed time from the epoch in UTC. It is not a calendar string. It does not store a timezone. It is “this many SI seconds (ignoring leap-second subtleties in most systems) since the epoch,” usually exposed as an integer.

Example: 0 is the epoch itself. 1700000000 is a moment in November 2023 in UTC when interpreted as seconds. Display that same instant in New York or Tokyo and the clock face changes, but the timestamp number does not.

Why systems use it

• Sorting and math — subtract two stamps to get a duration in seconds
• Language neutrality — no locale-specific month names on the wire
• Storage — compact in databases and binary protocols
• Interoperability — nearly every platform can convert to and from epoch

Human-facing UIs should show local or explicitly labeled times. Storage and APIs often keep epoch or an unambiguous ISO string. Convert either way with the timestamp converter when you need a second opinion next to your code.

Both appear in the wild. Classic Unix time is seconds. Many JavaScript APIs and some databases use milliseconds since the epoch. Confusing them shifts your date by a factor of 1,000 — often into 1970 or the far future.

How to tell them apart

• ~10 digits (around 1e9–1e10 for current decades) — usually seconds
• ~13 digits (around 1e12–1e13) — usually milliseconds
• ~16 digits — sometimes microseconds; confirm with the docs

JavaScript’s Date.now() returns milliseconds. new Date(seconds * 1000) is a common fix when an API returns seconds but the Date constructor expects ms. Python’s time.time() is seconds as a float. Always read the field description: created_at alone does not tell you the unit.

Worked intuition

If you convert a “current” looking number and get a date in 1970, you probably fed milliseconds into a seconds-based converter (or divided wrong). If you get a year far in the future, you may have treated seconds as milliseconds. The online timestamp converter that supports both units lets you flip modes quickly while debugging.

For other unit mix-ups (not time), a general unit converter or the unit conversion guide uses the same discipline: know the unit before you convert.

ISO 8601 is a text format for dates and times, for example 2026-08-03T14:30:00Z. The trailing Z means UTC. Offsets like +02:00 mean local civil time that far ahead of UTC. Unix timestamps and ISO strings represent the same instants when converted carefully.

When to prefer which

• Unix timestamp — compact, easy numeric comparisons, common in logs and some DB columns
• ISO 8601 — readable in JSON APIs, unambiguous with offset or Z, good for config and exports
• RFC 2822-style — still appears in email and some HTTP headers

JSON payloads often mix both: a numeric ts field next to an ISO createdAt. Pretty-print the body with a JSON formatter so you can see which field is which, then convert the number in the timestamp converter.

Fractional seconds

ISO strings may include fractional seconds (.123). Millisecond timestamps map cleanly to three fractional digits. Truncation versus rounding can matter in tests that expect exact equality — compare with a tolerance when clocks and serializers disagree by a millisecond.

A Unix timestamp is timezone-agnostic: it names an instant. Timezones affect only how you display or construct that instant from civil date parts (year, month, day, hour).

Common mistakes

• Parsing 2026-08-03 as UTC in one system and as local midnight in another
• Storing “local wall time” without an offset, then treating it as UTC later
• Formatting a UTC instant with a local zone and logging it without a zone label
• Assuming DST rules never change — libraries must ship zone data updates

Best practice for servers: store UTC instants (epoch or ISO with Z), convert to the user’s zone only in the UI or in reports that explicitly need local time. When two logs disagree by several hours, check zone labels before you blame clock skew.

Relative phrases like “3 hours ago” are derived from the difference between now and the timestamp. They still depend on both clocks being roughly correct. For scheduling across zones, prefer explicit ISO offsets over free-text city names unless you use a proper timezone database.

Convert with an explicit zone mode in the timestamp converter and compare UTC versus local output so the offset is visible, not implied.

Production incidents often start with three lines of logs from three services and three different time formats. Your job is to align them on one timeline.

1. Extract every timestamp from the incident window.
2. Normalize units (seconds vs ms) and formats (epoch vs ISO).
3. Convert everything to UTC for comparison.
4. Sort events and look for causal order, not just wall-clock labels in mixed zones.
5. Watch for clock skew: containers without NTP can drift minutes.

Correlation IDs help

Timestamps alone are not enough when two requests share the same second. Pair time with request IDs or UUIDs. Generating and recognizing those IDs is covered in the UUID generator guide; for minting values while you test, use a UUID generator.

When log lines embed JSON, format them first with the JSON formatter guide workflow, pull the epoch field, and convert. If a field is Base64-wrapped metadata, decode with a Base64 decoder before you hunt for times inside.

Keep a converter tab open during on-call. Speed matters more than memorizing epoch tables.

Going from a calendar date to epoch means: interpret the civil fields in a known timezone, then compute seconds or milliseconds since 1970-01-01T00:00:00Z.

Practical steps

1. Write the full date and time, not just the day, unless you truly mean midnight.
2. State the timezone or use UTC explicitly.
3. Convert to an instant, then to seconds or ms as your system requires.
4. Round-trip: convert back to ISO and confirm you did not shift a day at zone boundaries.

Ambiguous local times during DST fallbacks (the same hour occurs twice) need a rule: pick offset, pick earlier/later, or store UTC only. APIs that accept “date only” for deadlines should document whether the boundary is end-of-day UTC or end-of-day in a business zone.

The free timestamp converter supports date-to-epoch and epoch-to-date so you can verify library output without deploying a one-off script. For date arithmetic (add days, span between dates) beyond pure epoch math, a date calculator may be a better fit.

A short checklist prevents recurring bugs:

• Unit mismatch — seconds vs milliseconds is still the top offender
• 32-bit overflow myths — classic 2038 issues hit 32-bit time_t; modern 64-bit systems are fine for normal app use, but embedded gear may not be
• Leap seconds — most app stacks ignore them; do not build financial-grade schedules on naive assumptions without reading your platform docs
• String sorting of local formats — 03/08/2026 is ambiguous across locales; prefer ISO or epoch for interchange
• Client clock trust — never authorize a request solely because the client sent a “fresh” timestamp; use server time

Document the unit next to every API field: expires_at_ms is clearer than expires. In code reviews, flag bare Date parses of numeric strings without multiplication or division checks.

Convert live with the timestamp converter, keep payloads readable with the JSON formatter validator, and treat encoding layers separately via the Base64 encoding guide when timestamps hide inside encoded blobs.