Timestamp to ISO 8601

Turn an epoch value into ISO 8601 and RFC 3339 strings with the precision and offset you need. Rounding is explicit, never accidental.

Nowreading device clock…
Unix number in any unit, ISO 8601, RFC 2822, Excel serial, FILETIME, UUID, ULID or Snowflake.
Unit
IANA zone; type to search, e.g. Kolkata, Paris.
Precision and rounding
Same digits in other units
Other formats this number could be (4)
UTCUTC+00:00
2026-01-01 Thu
00:00:00.500
Asia/TokyoUTC+09:00
2026-01-01 Thu
09:00:00.500

Read as Unix seconds (unit locked) high confidence

Precision check: exact vs JavaScript Number and Date
Exact (BigInt)
1 767 225 600 500 000 000 ns
Number(input)
1767225600 (no loss)
new Date(ms)
no loss
Unix epoch
Unix seconds1767225600.5Exact; fraction shown when present
Unix seconds (integer, floor) rounded1767225600Sub-second part dropped (floor)
Unix milliseconds1767225600500
Unix microseconds1767225600500000
Unix nanoseconds1767225600500000000
Unix seconds (hex) rounded0x6955B900
Standard date formats
ISO 8601 (UTC)2026-01-01T00:00:00.500Z
RFC 3339 (Asia/Tokyo)2026-01-01T09:00:00.500+09:00
RFC 9557 (offset + zone)2026-01-01T09:00:00.500+09:00[Asia/Tokyo]
RFC 2822 (Asia/Tokyo) roundedThu, 01 Jan 2026 09:00:00 +0900Whole seconds only
HTTP-date (IMF-fixdate) roundedThu, 01 Jan 2026 00:00:00 GMTAlways GMT; whole seconds
SQL TIMESTAMP (UTC)2026-01-01 00:00:00.500Microsecond precision max (PostgreSQL/MySQL)
SQL TIMESTAMP (Asia/Tokyo wall time)2026-01-01 09:00:00.500No zone stored: ambiguous without context
PostgreSQL timestamptz literal2026-01-01 09:00:00.500+09:00
ISO week date (Asia/Tokyo)2026-W01-4
Ordinal date (Asia/Tokyo)2026-001
Readable (Asia/Tokyo)Thursday, 1 January 2026, 09:00:00 GMT+9Canonical English; not locale-dependent
Platform and system epochs
JavaScript new Date(ms)new Date(1767225600500)
Java InstantInstant.ofEpochSecond(1767225600L, 500000000L)Nanosecond precision
Python datetime (UTC)datetime(2026, 1, 1, 0, 0, 0, 500000, tzinfo=timezone.utc)Microsecond precision
.NET DateTime ticks639028224005000000100-ns ticks since 0001-01-01 (DateTime.Ticks with Kind=Utc).
Windows FILETIME / LDAP134116992005000000100-ns intervals since 1601 UTC. Active Directory lastLogon, pwdLastSet, accountExpires.
Chrome / WebKit time13411699200500000Microseconds since 1601 UTC (Chrome history, cookies).
Apple Cocoa / Core Data788918400.5NSDate timeIntervalSinceReferenceDate, Core Data, iOS/macOS plists.
Mac HFS+ seconds rounded3850070400Classic Mac OS / HFS+ volume dates (seconds since 1904).
NTP seconds (era 0)3976214400.5NTP era 0 wraps on 2036-02-07; era numbers are not encoded in the 32-bit field.
Excel serial 1900 (Asia/Tokyo wall time) rounded46023.375005787Days since 1900-01-00 with the Lotus 1-2-3 leap-year bug (serial 60 = fictitious 1900-02-29). No time zone.
Excel serial 1904 (Asia/Tokyo wall time) rounded44561.375005787Older Mac Excel workbooks. Days since 1904-01-01. No time zone.
Julian Date rounded2461041.500005787Days since noon UT, 24 Nov 4714 BC. Computed from UTC, so it ignores the UT1/TT distinction.
Modified Julian Date rounded61041.000005787JD - 2400000.5. Computed from UTC.
GPS seconds1451260818.5Seconds since the GPS epoch, counting leap seconds (GPS = TAI - 19 s). Uses the bundled leap-second table.
TAI (TAI-UTC = 37 s)2026-01-01T00:00:37.500 TAIFrom the bundled leap-second table
ID range bounds
Smallest UUIDv7 at this ms019b76da-a9f4-7000-8000-000000000000Use as a range-query lower bound
Smallest ULID at this ms01KDVDNAFM0000000000000000
Smallest Twitter / X Snowflake2006515715535798272
Smallest Discord Snowflake1456074446077952000
Smallest MongoDB ObjectId6955b9000000000000000000
Settings and local data

Storage: checking…

ISO 8601 or RFC 3339?

RFC 3339 is a strict profile of ISO 8601 for internet protocols. It requires a full date, a full time and an offset (Z or ±hh:mm). ISO 8601 allows more shapes: week dates such as 2026-W44-5, ordinal dates such as 2026-303, basic format without separators, and reduced precision. The outputs list includes UTC with Z, the selected zone's RFC 3339 form, and an RFC 9557 form that adds the IANA zone name in brackets so the zone survives a round trip.

Fractional precision and rounding

Choose 0, 3, 6 or 9 fractional digits, or Auto. Auto keeps the precision of the input and shows every non-zero digit. When fewer digits are requested, the rounding mode decides the result. Floor (the default) always moves toward the earlier instant, which matches how Unix tools truncate timestamps and keeps an event in the second it actually happened. Ceil, truncate toward zero and round-half-away-from-zero are also available. Rows that were rounded are marked so you never copy a rounded value by mistake.

Questions

What does the Z at the end mean?
Z (Zulu) is the designator for UTC, equivalent to +00:00. RFC 3339 also defines -00:00 to mean "UTC, local offset unknown".
How many fractional digits should I use?
Match the source precision: 3 for milliseconds, 6 for PostgreSQL/Python microseconds, 9 for nanoseconds. Extra trailing zeros are harmless, but dropping digits loses information.
Is the offset the same all year?
Not for zones with daylight saving time. The offset shown is the one in effect at the converted instant.