Unix Timestamp Converter

Unix timestamp resolution

Seconds:      1700000000        (10 digits, ~Nov 2023)
Milliseconds: 1700000000000     (13 digits, JS Date.now())
Microseconds: 1700000000000000  (16 digits, Python time_ns / 1000)
Nanoseconds:  1700000000000000000 (19 digits, Go time.UnixNano)

ISO 8601 — the human-readable standard

2026-05-06T14:30:00Z          UTC ("Z" = Zulu time)
2026-05-06T14:30:00.123Z      with milliseconds
2026-05-06T14:30:00+09:00     with timezone offset
2026-05-06                    date only
P1Y2M10DT2H30M                ISO 8601 duration (1 year 2 months 10 days...)

RFC formats

RFC 9110 (HTTP):  Wed, 06 May 2026 14:30:00 GMT
RFC 2822 (email): Wed, 06 May 2026 14:30:00 +0000
RFC 3339:         2026-05-06T14:30:00.123Z (subset of ISO 8601)

Conversion in popular languages

JavaScript:  Date.now()                   → ms timestamp
             new Date(ts * 1000).toISOString()
Python:      time.time()                  → float seconds
             datetime.fromtimestamp(ts).isoformat()
Go:          time.Now().Unix()            → seconds (int64)
             time.Unix(ts, 0).Format(time.RFC3339)
Bash:        date +%s                     → seconds
             date -u -d @1700000000        → UTC date

1. Seconds vs milliseconds confusion

JavaScript's Date.now() returns milliseconds. Most other languages return seconds. Mixing them silently produces dates 1,000× off — your Nov 2023 timestamp becomes year 55,793. Always verify the unit when consuming an API you didn't write.

2. Year 2038 problem

32-bit signed integers overflow at 2147483647 (2038-01-19T03:14:07Z). Legacy C code, MySQL TIMESTAMP (pre-8.0), and embedded systems are affected. Use 64-bit integers (BIGINT) or the DATETIME type for forward compatibility.

3. Leap seconds and "Unix time"

Strictly, Unix time is not seconds since the epoch — it's UTC seconds counted with leap seconds smeared out. On a leap second day, Unix time stays still or repeats. Most code doesn't notice; only nanosecond-precise systems (financial trading, GPS) need to handle it (POSIX CLOCK_TAI).

4. Local time → UTC ambiguity

Converting "2026-03-09 02:30 PT" to a timestamp is ambiguous in the US — that hour doesn't exist (DST spring-forward) or repeats (fall-back). Always store timestamps in UTC and convert only at display time. Never store local time without an offset.

5. Comparing timestamps with strings

Two ISO 8601 strings can be lexically compared if they're both in UTC ("Z") and have consistent precision. But "2026-05-06" < "2026-05-06T00:00:00Z" lexically. To be safe, always parse to a Date / timestamp before comparing.

What is the difference between seconds and milliseconds?

Unix timestamps in seconds have 10 digits (e.g., 1700000000); milliseconds have 13 digits (e.g., 1700000000000). This tool auto-detects. JavaScript's Date uses milliseconds; most other languages use seconds.

What is the Year 2038 problem?

Signed 32-bit integers max out at 2147483647 — which corresponds to 2038-01-19T03:14:07Z. Legacy systems storing Unix time in 32-bit signed integers will overflow then. Modern systems use 64-bit integers, pushing the next overflow ~292 billion years out.

Why is "Z" used for UTC?

"Z" stands for "Zulu time" — the NATO phonetic alphabet letter for the +0 timezone. It's a one-character shorthand for +00:00 in ISO 8601.

Should I store dates as Unix timestamps or ISO strings?

Unix timestamps for compactness and arithmetic — preferred for high-frequency time fields (event logs, metrics). ISO 8601 for human-readable APIs and debugging — preferred for user-facing fields (created_at, updated_at). Either way, always UTC at storage; convert to local only at display.

How do I get the current timestamp?

JavaScript: Math.floor(Date.now() / 1000). Python: int(time.time()). Go: time.Now().Unix(). Bash: date +%s. The live timestamp at the top of this tool also shows the current second.