English

Developer tools · Unix timestamp converter

Not every epoch is 1970: NTP, Windows FILETIME, GPS and Excel dates

· Background

timestamps data-formats debugging

Several timelines with different zero points converging on one instant
Original ToolAcre vector illustration

Unix's 1970 origin is only one of many. This post surveys the epochs you will meet in files and protocols (1900, 1601, 1904, 1980, 2001) and shows how to recognise a value that was never Unix time at all.

The timestamp that landed in 1900 — a value from a network capture that no unit choice could make sensible

A number from a packet capture can produce nonsense under both seconds and milliseconds because the unit is not the only hidden parameter. Epoch means a chosen zero point; Unix uses 1970, while another protocol may count from somewhere else. Rescaling cannot repair the wrong origin.

When both ToolAcre readings conflict with known event time, stop toggling. Identify the field name, producer, protocol version and documented origin. Repeatedly trimming digits until a plausible year appears converts investigation into coincidence.

The same diagnostic applies when a sensible date appears but conflicts with surrounding events. Plausibility is a weak check; provenance and a known reference event are stronger.

NTP and 1900 — seconds since 1900-01-01 with a 32-bit fraction, and the 2036 rollover it brings

The workbook supplied NTP’s origin, fractional layout and rollover date. None is implemented or tested in the Unix converter, so this article does not certify those specifics. A network capture must be decoded according to the protocol documentation used by the sender and parser.

Only after deriving Unix seconds should the value enter this tool. Keep era or rollover context because one fixed-width field may not identify it alone. A polished UTC result from an assumed era can be internally consistent and externally wrong.

Protocol fields can also split whole and fractional components. Concatenating or decimalizing them without the specified scale creates a new number that no compliant decoder intended.

NTP conversion details and rollover behavior require source documentation not present here

Likewise, the named Windows and .NET counters are not accepted modes. The repository contains no constants for their origins or tick scales. Their large decimal values may exceed JavaScript’s exact integer range before a developer attempts conversion.

Use an integer-safe library grounded in the platform’s documented definition, preserve the original as text or wide integer, and then emit a Unix value. Do not subtract a remembered offset in floating point. Exactness at the low end matters when the source resolution is finer than milliseconds.

A round-trip test should include a value with nonzero sub-second digits. Whole-second fixtures cannot expose whether the 100-nanosecond or millisecond remainder was preserved correctly.

FILETIME and .NET definitions are not implemented by ToolAcre and are not asserted from memory

Spreadsheet dates introduce a different representation: a numeric serial interpreted by workbook date-system settings. The workbook’s 1900 quirk and older Mac claim require spreadsheet sources and are not established here. ToolAcre does not read workbook metadata.

Inspect the file with spreadsheet-aware tooling, determine the configured date system and preserve fractional-day precision using that library. Treating a serial as Unix seconds can produce an early-1970 date that looks like an ordinary scale bug while the actual problem is origin and unit together.

Workbook settings can travel with a file, so two visually similar serials may use different origins. Conversion belongs at the document boundary where that metadata is available.

Spreadsheet serial systems and quirks require spreadsheet-specific evidence

GPS and Apple-related epochs named in the outline are also outside the implementation. Their relationships may involve scale conventions beyond a constant origin shift. No current offset or conversion formula is published here without authoritative evidence.

The general diagnostic still transfers: identify zero, tick duration and leap convention from the producer. Then convert with an appropriate library and verify against a known timestamp from the same data set. Three independent facts are safer than a decimal-width guess.

That caution is particularly important around leap conventions. A constant that works for one scale and date may not be a timeless relationship between every pair of systems.

GPS and Apple epoch relationships require authoritative sources outside this module

A defensible worked method starts with a known instant, for example ToolAcre’s verified `2025-02-03T10:23:00.000Z`, equal to 1,738,578,180 Unix seconds. For another documented epoch, compute its value using that system’s official origin and scale with integer arithmetic, then convert it back using the same definition.

Compare the round trip to the Unix ISO string and retain the derivation. This article intentionally does not fill a five-epoch table with constants that were not read. The method exposes every assumption and can be reviewed against whichever protocol or file format actually produced the data.

Worked method: derive one instant across documented epochs rather than publishing unverified constants

ToolAcre does not automatically recognize or convert foreign epochs. Its unit menu says seconds and milliseconds, both under the Unix definition in the config. Automatic detection only chooses between those scales at magnitude 10¹¹; it never changes the zero point.

That narrow contract prevents false confidence. If a foreign count happens to land on a plausible Unix date, the converter cannot warn that the origin was wrong. Provenance must enter before arithmetic. Document the transformation in code rather than relying on a manual runbook.

The visible automatic label only reports seconds or milliseconds. It should never be cited as evidence that origin detection occurred, because no such branch exists in source.

Takeaway: know which zero you are counting from — and how the Unix timestamp converter tells you plainly that it reads Unix seconds or milliseconds

Know which zero you are counting from, how large one tick is and how the source handles its time scale. A Unix converter answers only after those questions resolve to seconds or milliseconds since 1970 UTC. It cannot infer semantics from one integer.

Use implausible dual readings as a signal to investigate origin, not as permission to keep trying divisors. Once a sourced conversion produces a Unix value, ToolAcre provides a useful independent UTC and local sanity check while keeping its own assumption visible.

A good adapter names the foreign type, performs one sourced transformation and emits a branded Unix value. That design prevents raw counters from leaking into generic date constructors.