NTP Timestamp Converter — Seconds Since 1900

The NTP epoch

When NTP was designed, the natural epoch was January 1, 1900. The gap to the Unix epoch (1970) is exactly 2208988800 seconds, so the conversions are:

• NTP → Unix: unix = ntp - 2208988800.
• Unix → NTP: ntp = unix + 2208988800.

The current time is about 3995049600 NTP seconds — note that this is already over 2³¹, which is why NTP packets split the field into seconds and a fraction.

The 64-bit packet format

NTP packets carry timestamps as two 32-bit words: a seconds field since 1900 and a fraction field that divides the second into 2³² parts. The tool's "64-bit NTP hex" row shows both words side by side, so you can match a value against a packet capture:

• 3995049600 seconds → hex seconds word ee26c000.
• The fraction 0.5 → hex fraction word 80000000 (half of 2³²).

Example conversions

• 2208988800 → January 1, 1970 00:00:00 UTC — the Unix epoch, in NTP terms.
• 3995049600 → August 7, 2026 00:00:00 UTC.

In your own code

• Python: datetime.fromtimestamp(ntp - 2208988800, tz=timezone.utc).
• Go: time.Unix(int64(ntp-2208988800), 0).UTC().
• C#: DateTimeOffset.FromUnixTimeSeconds((long)(ntp - 2208988800)).

Gotchas

• Era rollover in 2036 — the 32-bit seconds field wraps on February 7, 2036. After that, NTP "era 1" values (2³² + offset) still decode correctly here because the arithmetic is continuous.
• Fractions — a decimal input like 3995049600.5 means half a second; the tool converts both the decimal and the 32-bit fraction word.
• Don't mix epochs — adding 2208988800 to a value that is already Unix time lands you 70 years in the future. Check which clock produced the value.
• NTP era 0 vs 1 — logs sometimes show raw 32-bit fields after the 2036 wrap; add 2³² if the date looks ~136 years in the past.

Related tools

Prefer the modern epoch? Use theUnix timestamp to date converter, or theGPS time converter for the other major atomic-time scale.