NTP era 0

NTP Timestamp

Seconds since 1900-01-01 UTC (wraps in 2036).

NTP timestamp

Paste an NTP second count (decimal or hex), or pick a date.

Unix Timestamp Epoch seconds ↔ human-readable date Converters Unix, Excel, FILETIME, ISO 8601, and calendar converters FILETIME Converter Windows FILETIME / LDAP timestamp converter Excel Date Converter Excel serial date \u2194 calendar date ISO 8601 Converter ISO 8601 and RFC 2822 date formats Year 2038 Problem Y2038 epoch overflow explained with converter

NTP timestamps count seconds since 00:00:00 UTC on 1 January 1900. Era 0 is the 32-bit seconds field used in classic NTP packets; it wraps when 2^32 seconds have elapsed, which falls in early February about 136 years after 1900. Paste a decimal second count or an 8-digit hex seconds field, or pick a UTC date to encode midnight. Unix time starts in 1970, 2,208,988,800 seconds later. GPS and TAI are different scales again. This page is for packet dumps and protocol clocks, not for civil meeting math.

1900, not 1970, and not 1980

Unix POSIX time is seconds from 1970-01-01. Subtract 2,208,988,800 from an era-0 NTP seconds field (when it still represents a post-1970 instant) to reach Unix seconds. Adding that same delta to Unix seconds produces NTP seconds. The page prints both so you can cross-check against the Unix timestamp converter. A value near 3.9 billion is a plausible current-era NTP second; a 10-digit Unix second near 1.7 billion is not NTP.

GPS time starts on 6 January 1980 and ignores leap seconds in a different way. TAI is a continuous atomic count. NTP’s 32-bit seconds field is specified relative to 1900 and is commonly interpreted with leap-second conventions that do not match GPS week/TOW. Convert GNSS logs on the GPS time page. Convert NTP on this page. Do not prefix gps: here; there is no GPS week field in the form.

SNTP and NTPv4 packets also carry a 32-bit fraction (subsecond). This UI focuses on the seconds field. Hex input of 8–16 hex digits uses the first eight as seconds. A 64-bit dump should not be parsed as one huge decimal if the high bits are the seconds field and the low bits are fraction; split the fields first.

The 32-bit wrap

Era 0 overflows at 2^32 seconds after 1 January 1900 UTC, on 7 February about 136 years after 1900 at 06:28:16 UTC. After that instant, a naïve 32-bit seconds field restarts. RFCs describe era 1 and 64-bit NTP timestamps so clocks can continue. This converter warns when an encoded date is past the 32-bit era-0 rollover and still shows a full second count for date-to-NTP direction.

Firmware that stores only 32 bits will look like 1900-era dates if you decode a post-wrap field as era 0 without adding 2^32. The same class of bug as GPS 10-bit week rollover, with a different period and epoch. Inventory scripts for 2026 should note whether devices will still be in service when era 0 wraps, and whether they already speak 64-bit NTP.

JavaScript Date cannot express every NTP theoretical value. Out-of-range conversions are rejected. That is a browser limit, not an NTP spec limit. Lab tools that need pre-1900 or far-future instants should use a dedicated time library, not this form.

Hex packet dumps

Wireshark and hex dumps often show the NTP seconds field as eight hex characters, sometimes prefixed with 0x, sometimes with a dotted fraction. Paste 8 hex digits, optional 0x, optional extra fraction digits (the extra is stripped after the first eight). Decimal pastes must be all digits. Ambiguous strings that are neither are ignored and the date picker is used if filled.

Byte order in a packet is network big-endian. If you copied from a little-endian memory dump of a host struct, swap the bytes before pasting. A seconds field that decodes to a date in 1969 or to a wrap-era nonsense date is often an endian mistake or a Unix field mislabeled as NTP.

Originate, receive, and transmit timestamps in one NTP packet are four separate 64-bit values. Convert each seconds field on its own. Subtracting two NTP timestamps to get delay is protocol math; this page only maps one field to UTC.

Worked conversions

Pick 1 January 2026 00:00 UTC. Read NTP seconds and the 8-digit hex seconds field. Recode the hex on a second pass and confirm the ISO line returns the same midnight. That round-trip is the unit test for a parser.

Paste 2208988800 (decimal). UTC should be the Unix epoch, 1 January 1970. That constant is the NTP–Unix delta and belongs in every interop comment. Paste 0. UTC should be 1 January 1900. Negative Unix seconds for pre-1970 NTP values are expected; they are not a parse error.

A pcap shows e2d5 something in the seconds field. Paste the eight hex characters. If the civil date matches the capture time, the field is NTP seconds. If it matches 1970-ish, you may have Unix in hex instead—open the Unix converter (including hex Unix if you have that page) rather than adding 1900 by hand.

Leap seconds and smearing

NTP can represent leap-second state in packet flags. Civil UTC days in this converter still follow POSIX-like 86400-second labels via JavaScript Date. Do not use this page to prove whether a leap second was inserted. The IERS table and the GPS / TAI converter are closer to that question. NTP smear deployments (smearing the leap over a day) make packet timestamps look smooth; the seconds field still ticks 86400 labels that day.

Clock offset, delay, and stratum are NTP algorithms, not timestamp encodings. A timestamp can be valid while the host is unsynchronized. Decoding UTC from a packet does not mean the sender was right. Compare several servers if the incident is “who has the wrong clock.”

Related civil planning still uses ordinary calendars: converters hub for other encodings, and date or time hubs when the question is no longer a protocol field.

Related tools

POSIX seconds: Unix timestamp. GNSS scales: GPS time. Encoding index: converters hub.

Frequently asked questions

What epoch does an NTP era-zero seconds field count from?

It counts seconds from 00:00:00 UTC on 1 January 1900. That is seventy years before the Unix epoch. The 32-bit era-0 field wraps 2 to the 32nd seconds later, in early February about 136 years after 1900. GPS weeks and TAI seconds use other starting points and should not be pasted here unlabeled.

How do I convert NTP seconds or hex into UTC?

Paste a decimal second count, or eight hex digits for the seconds field (optional 0x, extra fraction digits ignored after eight). The page prints UTC ISO, Unix seconds, and a wrap note. You can also pick a calendar date to encode midnight UTC as NTP seconds and hex. Split 64-bit dumps into seconds and fraction first.

Why does the 32-bit NTP seconds field wrap after 1900?

A 32-bit unsigned counter overflows at 4,294,967,296 seconds after 1 January 1900, which is 7 February about 136 years later at 06:28:16 UTC. Era 1 and 64-bit timestamps exist so clocks can continue. Decoding a post-wrap 32-bit field as era 0 without adding 2 to the 32nd yields a bogus early date.

Is NTP the same numbering system as Unix or GPS time?

No. Unix counts from 1970; the NTP–Unix delta is 2,208,988,800 seconds. GPS counts from 6 January 1980 with week and seconds-of-week fields and a leap-second offset versus UTC. TAI is a continuous atomic scale. Use this page for NTP, the Unix converter for POSIX, and the GPS page for week and TOW.

When should packet dumps use hex instead of decimal NTP seconds?

Use hex when Wireshark or a memory dump shows the 32-bit seconds field as eight hex characters. Use decimal when a log already printed the integer. Hex from a little-endian host struct may need a byte swap first. A field that decodes to 1969 often is Unix mislabeled as NTP, or the wrong endianness.

How many seconds separate the NTP epoch from the Unix epoch?

2,208,988,800 seconds. Pasting that decimal NTP value should decode to 1 January 1970 00:00:00 UTC. Adding the same delta to a Unix second produces the NTP second for that instant while era 0 still fits in 32 bits. After the wrap, 64-bit NTP is required for an unambiguous seconds field.

Processing, please wait...