Unix Timestamps Explained: Why Computers Count Time From 1970 (and How Time Zones Break Things)

By Priya Raghunathan · October 6, 2026 · Time & Date

A Unix timestamp is the seconds since midnight on 1 January 1970. It is elegant, timezone free and the source of a surprising number of bugs when humans get involved.

Behind almost every clock on a modern computer is a single integer: the number of seconds that have elapsed since midnight UTC on 1 January 1970. This is the Unix timestamp, and it is the cleanest representation of time we have, because it has no time zone, no daylight saving and no calendar ambiguity. The complications arrive only when we convert that integer into something a human reads, and that conversion is where most time related bugs are born.

In this article:

Why 1970 and what the integer means

The Unix epoch was chosen in the early 1970s as a convenient round number for the systems being built at the time, and a signed thirty two bit integer counting seconds from it was more than enough to cover any plausible date. That integer is the timestamp. The value one billion corresponds to a specific moment in September 2001, and the value at the time of writing is well over one point seven billion. Because it is a simple count, comparing two timestamps or subtracting them is trivial arithmetic, which is why databases and logs store time this way.

Timestamps and time zones

A timestamp always represents a moment in UTC, the global reference. When a human needs to read it, the system applies a time zone offset to produce a local wall clock time. The same timestamp renders as a different local time in every zone, but it always refers to the same instant. This is the property that makes timestamps safe for storage: two systems in different zones comparing the same timestamp agree on the moment, even if they display it differently.

The bugs come from mixing the two representations carelessly. Storing a local wall clock time as if it were a timestamp, without applying the offset, shifts every event by hours. Reading a timestamp and displaying it without a zone leaves the reader guessing which region it represents. And daylight saving means the offset for a given zone changes through the year, so a timestamp rendered in June and January produces different local times for the same offset value.

Leap seconds and the year 2038

Two long standing edge cases deserve mention. Leap seconds, added occasionally to keep clock time aligned with Earth's rotation, are not represented in the Unix timestamp, which counts every day as exactly eighty six thousand four hundred seconds. Most systems smear the leap second across a window, so timestamps remain continuous at the cost of a tiny inaccuracy. The year 2038 problem is more concrete: a signed thirty two bit integer reaches its maximum early in that year and overflows. Systems using sixty four bit integers, which is now the norm, are unaffected, but embedded and legacy systems may need attention.

Worked examples converting timestamps

Example one: a timestamp to a human date

The timestamp one billion, when rendered in UTC, is the ninth of September 2001 at one minute and forty six seconds past one in the morning. Rendered in New York, which is four hours behind UTC at that date, it is the eighth of September 2001 at nine forty six in the evening. Same instant, different wall clock, and the date itself differs by one because the conversion crossed midnight.

Example two: a local time stored wrongly

Suppose an event at two in the afternoon London time on a given date is recorded as the timestamp for two in the afternoon UTC, ignoring the one hour offset. The stored timestamp is one hour earlier than the real moment. When rendered back in London it shows one in the afternoon, and when rendered in New York it shows five hours earlier than it should. A single missing offset has corrupted the record for every zone.

Example three: a daylight saving trap

A daily report scheduled for two thirty in the morning is stored as a local time. When daylight saving ends and clocks fall back, two thirty in the morning occurs twice on that date, and the scheduler must decide which occurrence it means. Storing the schedule as a timestamp with the correct offset removes the ambiguity entirely, because each occurrence has a distinct timestamp.

Common mistakes

FAQ: timestamp edge cases

Why use seconds rather than milliseconds?

The original Unix definition uses seconds. Many modern systems, including JavaScript, use milliseconds for finer resolution. Always confirm the unit before comparing or converting, because mixing them is a common and silent bug.

Do timestamps include leap seconds?

Strictly, no. Unix time pretends leap seconds do not exist and counts every day as a fixed length. Practical systems handle this by smearing the extra second, so timestamps stay continuous.

Is the year 2038 problem still relevant?

For systems using sixty four bit time, no. For embedded devices and legacy code using thirty two bit signed integers, yes, and they should be identified and updated before the overflow.

Wrapping up

A Unix timestamp is the cleanest way to store a moment, because it is a single integer in UTC with no zones or daylight saving. Convert to local time only at the point of display, always record the offset, and be careful with units and transition days. Treat the integer as the truth and the wall clock as a presentation, and most time bugs disappear.

Convert between Unix timestamps and human readable dates instantly.

Try the Date Calculator tool.

SwiftMultiTool — free online tools for everyone. Home · Blog · About · FAQ · Contact