Unix Timestamp Converter

Seconds versus milliseconds, and how to tell them apart

Two conventions are in simultaneous use, and confusing them is the single most common timestamp bug. Unix time in seconds is the original POSIX definition. Many modern languages and platforms — JavaScript, Java, and several database drivers — work in milliseconds instead.

The digits give it away, and one comparison is usually enough:

• 10 digits — seconds. In the range of roughly 1.0 to 2.1 billion, covering dates from 2001 to 2038.
• 13 digits — milliseconds. Around 1.7 trillion for the present day.
• 16 digits — microseconds, used in some logging systems.
• 19 digits — nanoseconds, as used by Go and some monitoring stacks.

The reason the distinction is worth automating is that the failure is silent. Interpret a millisecond value as seconds and you get a date about fifty thousand years in the future; interpret a second value as milliseconds and you land in January 1970. Neither throws an error, and both look like valid dates.

Auto-detection here works on magnitude: any value above roughly 10^11 is treated as milliseconds, because as seconds it would represent an implausibly distant date. That rule holds for any realistic timestamp from 1973 onwards. For values outside that range, set the unit manually.

Why the same timestamp shows two different times

This is the source of most confusion about timestamps, and it resolves quickly once the distinction is clear.

A Unix timestamp is a count of seconds since an instant, and that instant is a single point in time regardless of where you are. What changes with location is not the instant but the label you attach to it. When it is 10:30 in London it is 18:30 in Shanghai and 05:30 in New York, and all three describe the same moment.

The tool shows both readings deliberately:

• UTC is the invariant one. Two systems in different regions that both store UTC will always agree, which is why storage and transport should use it.
• Local time is your device timezone applied for display. It is what a person expects to see, and it is the wrong thing to store.

The practical rule is to store and transmit UTC, and convert only at the point of display. Ambiguity arrives when a system stores local time without recording which zone, which works until a daylight-saving transition or a server moves region, and then produces off-by-one-hour errors that are painful to trace.

Daylight saving adds a second trap. A local timestamp that appears twice in a year — the hour that repeats when clocks go back — is genuinely ambiguous, and the offset recorded alongside it is what disambiguates. This is why ISO 8601 permits an explicit offset such as +08:00 rather than just a wall-clock reading.

The Year 2038 problem, explained properly

On systems that store Unix time in a signed 32-bit integer, the largest representable value is 2,147,483,647. That corresponds to 03:14:07 UTC on 19 January 2038. One second later, such a system overflows.

What happens at overflow is worth being precise about, because the naive description — that time goes backwards — understates it. In two-complement arithmetic the counter wraps to the largest negative value, which as a timestamp is 20:45:52 UTC on 13 December 1901. So a 32-bit system does not stall or crash; it silently reports a date a hundred and thirty-seven years in the past. Comparisons invert, expiries appear long expired, and scheduled work may run immediately or never.

The reassuring part is that most systems in general use are no longer exposed. Linux on 64-bit platforms has used a 64-bit time type since the 5.x kernel, and the same is true of modern Windows, macOS and the major server-side languages on 64-bit builds. A 64-bit counter overflows in the year 292 billion, which is not a scheduling concern.

Where the risk remains is embedded and long-lived:

• Industrial controllers, medical devices and building systems with decade-long service lives.
• 32-bit ARM and MIPS devices still fielded in large numbers.
• Legacy storage formats that wrote timestamps as 32-bit fields, including some file systems and archive formats, where the limitation is in the data rather than the code.
• Protocols and file formats that specified a 32-bit field and have not been revised, where changing the width requires breaking compatibility.

You can test any 32-bit ceiling directly here: enter 2147483647 and the converter will show you 19 January 2038, 03:14:07 UTC.

Leap seconds and why Unix time ignores them

Unix time counts seconds elapsed since 1 January 1970 UTC, and it deliberately does not count leap seconds. This is not an oversight; it is what makes arithmetic on timestamps trivial.

Earth rotation is not perfectly uniform, so UTC is periodically adjusted by one second to stay aligned with astronomical time. Twenty-seven leap seconds have been inserted since 1972. If Unix time counted them, then the interval between two timestamps would not straightforwardly equal the elapsed duration, and every subtraction would need a lookup table of insertion dates.

By ignoring leap seconds, Unix time guarantees that the difference between two values is exactly the number of seconds between those moments, except during the leap second itself. In exchange, Unix time is not a precise representation of UTC: at a leap second, a Unix clock repeats a value and is briefly out of step.

For application work this is the right trade. Where it is not is in astronomy, high-precision timekeeping, and satellite navigation, all of which track leap seconds explicitly because a one-second error matters. Those domains use different time scales, and the references are in the IAU and ITU standards rather than in POSIX.

One recent development is worth knowing: the international bodies responsible have agreed to stop inserting leap seconds by 2035, letting UTC drift from astronomical time. If that holds, the divergence becomes a problem for far-future civil timekeeping rather than for software.

Date formats you can type, and the ones that cause trouble

Accepted input includes ISO 8601 in both date-only and full form, the SQL convention with a space separator, and day-first slashed dates.

Examples that work:

2024-01-15
2024-01-15 10:30
2024-01-15T10:30:00Z
2024-01-15T10:30:00+08:00
15/01/2024

Three ambiguities are worth being aware of, because none of them is caught anywhere else:

Slash order. 01/02/2024 is 1 February in most of the world and 2 January in the United States. The tool reads slashed input as day-first, matching the international convention. When the order matters, use ISO 8601, where it cannot be misread.

Missing timezone. A value without Z or an offset is interpreted according to the Interpret as setting. If you are exchanging data between systems, always state the offset explicitly rather than relying on an agreed default, because that default is exactly the thing that gets forgotten.

Two-digit years. Avoid them entirely. The interpretation is library-specific, and the boundary between the twentieth and twenty-first centuries is handled inconsistently. Write four digits.

When generating output, ISO 8601 is the safe choice. It sorts lexicographically in the same order as it sorts chronologically, which means timestamped filenames and log lines order correctly under a plain alphabetical sort — a property no other common format has.