Unix timestamps,
in both directions

A Unix timestamp counts seconds since midnight UTC on 1 January 1970. That date has no special significance beyond being a round, recent-enough starting point when the convention was set at Bell Labs in the early 1970s.

The important property is that it carries no formatting and no time zone. It is a single integer naming one instant on the timeline, the same instant for everyone. Two systems in different countries that agree on a timestamp agree on the moment, even though they would print it differently.

Everything a human recognises as a date, the calendar, the clock, the zone, the daylight saving rule, is applied at display time. That separation is the whole reason the format is worth using.

The most common timestamp bug is a unit mismatch. Most backends, databases, and standards use seconds. JavaScript uses milliseconds. Passing one where the other is expected produces dates that are wrong by a factor of a thousand.

The failure is easy to recognise once you know the shape of it.

A signed 32-bit integer can hold values up to 2,147,483,647. As a count of seconds since 1970 that runs out at 03:14:07 UTC on 19 January 2038. One second later the value overflows into negative territory and the date reads as 13 December 1901.

It is the same class of problem as Y2K, and like Y2K most of it has been dealt with quietly. 64-bit time is standard on current systems, and a 64-bit signed count of seconds does not overflow for around 292 billion years.

What remains is embedded firmware, old file formats, and database columns that were declared as 32-bit integers years ago and never revisited. Anything storing a date past 2038, such as a long-dated contract or a certificate expiry, is where the problem shows up first.

The Earth’s rotation is not perfectly regular, so occasionally a leap second is added to keep civil time aligned with astronomical time. Unix time does not represent them. Every day is defined as exactly 86,400 seconds.

When a leap second occurs, the same Unix timestamp is used for two consecutive real seconds. The clock effectively pauses rather than counting past the boundary.

This is a deliberate trade. It means simple arithmetic on timestamps always works, and converting between a timestamp and a calendar date never needs a table of historical leap seconds. The cost is that the difference between two timestamps is not exactly the number of physical seconds that elapsed, which matters only in a handful of scientific and financial contexts.

A UTC offset such as +05:30 describes one moment. A time zone such as Asia/Kolkata describes a set of rules over time, including when daylight saving starts and stops and every historical change to the offset.

Storing an offset instead of a zone works until the rules move. A recurring 09:00 meeting in Europe/London is +01:00 in July and +00:00 in January. Store the offset and the meeting drifts by an hour twice a year.

Governments also change the rules with little notice, which is why the IANA time zone database is updated several times a year and why keeping that database current is a real operational task.

ISO 8601 is the interchange format worth standardising on: 2026-07-26T12:30:45Z. It sorts correctly as plain text, it is unambiguous about which component is the month, and every language can parse it.

The trailing Z means UTC, sometimes read as Zulu time. An offset can appear in its place, so 2026-07-26T18:00:45+05:30 describes the same instant as the example above.

A string with no zone at all is the one to be careful with. Its meaning depends on whoever parses it, and different runtimes disagree, so the same input can produce two different instants on two machines.