Unix Timestamp Converter

Counting the digits

The only genuinely tricky part of reading a timestamp is working out its unit, and magnitude settles it. There is no ambiguity in practice, because the ranges do not overlap for any date anyone is actually working with.

Getting it wrong is out by a factor of a thousand, so the result lands either in the early 1970s or tens of thousands of years in the future. Obvious when you look at it; entirely invisible when it is one column in a log table, which is where it actually bites.

What Unix time actually counts

Seconds since 00:00:00 UTC on 1 January 1970, assuming every day is exactly 86,400 seconds long.

That assumption is false. Leap seconds are inserted every few years to keep atomic time aligned with the Earth’s rotation, which is gradually slowing. Unix time does not represent them — systems repeat a second, or smear it across a day, so the count stays uniform.

The consequence is that Unix time is not a true count of elapsed seconds since 1970; it is about twenty-seven seconds short. For scheduling, logging and expiry that is exactly the right trade, because uniform arithmetic matters more than astronomical accuracy. For anything measuring real elapsed duration, use a monotonic clock instead — the wall clock can also jump backwards when NTP corrects it.

The 2038 problem

A signed 32-bit integer holds up to 2,147,483,647, which as a Unix timestamp is 03:14:07 UTC on 19 January 2038. One second later it overflows to negative and the date becomes December 1901.

Anything modern uses 64 bits and is good for roughly 292 billion years. What is not modern: embedded firmware, industrial controllers, some older database column types, and C code that still assumes a 32-bit time_t. The systems most at risk are the ones nobody is looking at, which is what made Y2K expensive too.

Which format to actually use

ISO 8601 in UTC, for anything crossing a boundary between systems or being read by a person:

2026-08-27T14:30:00Z

It is unambiguous, it sorts correctly as a plain string, and it is legible in a log at two in the morning. The Z matters: without it, most parsers assume local time, and you have invented a bug that only manifests for users in other countries.

Unix seconds are fine internally — they are what JWT exp and iat claims use, and integer comparison is cheap. The costs are that they are unreadable and that they invite the unit confusion above.

Worth avoiding: any format with an offset but no zone identifier (+01:00 does not tell you whether that is BST or CET, which matters for future dates), and anything in 03/04/2026 territory, which means two different days depending on which side of the Atlantic you read it on.

Storing future events

A subtlety that catches people out. For a meeting at 09:00 next March, storing UTC is wrong — if the timezone rules change between now and then, and governments do change them, the meeting moves. Future local events should be stored as a local time plus a zone identifier (Europe/London), and converted at display time using the rules current then. Past events are the opposite: UTC, because what happened is fixed.

Related

JWT exp and iat claims are Unix seconds — the JWT decoder converts them for you and flags expiry. For scheduling rather than converting, the cron parser shows when a schedule next fires.