Epoch Time Explained: The Epoch, UTC and the Year 2038 Problem

Epoch time is the system of counting time that most computers agree on: an integer that grows by one every second, starting from a fixed reference instant. That reference is the epoch, and for Unix and POSIX systems it is the first moment of 1970 in UTC. Once you see that the whole design is a count and a reference point, the rest - why there is no timezone, why 2038 matters, why negative values are legal - follows naturally. The historical background is covered in the Unix time article.

What is the epoch?

The epoch is the instant from which a system numbers time. For most modern systems it is 1970-01-01 00:00:00 UTC, and the current epoch time is the number of seconds between the epoch and now. Any moment can be named two ways: as a calendar date in a timezone, or as a single count from the epoch. The count version has no ambiguity about zones, calendars or daylight saving, which is why it is the format computers store.

Why was 1970 chosen?

Unix was built in 1969 at Bell Labs, and the first Unix time convention was settled as the system came together in 1970. The designers needed a reference instant and chose the start of that year, and because Unix and its standards spread, 1970 became the default epoch for the whole POSIX family. Other platforms made different choices: some Windows file timestamps count from 1601, and some mainframe and database formats use 1900. When a number converts to an unexpected date, checking the epoch of the source is a good reflex.

Is epoch time a timezone?

No, and this is the property that makes it useful. The epoch is anchored to UTC, so the count is identical for every observer. A timestamp does not say 14:30 in New York or 03:30 in Tokyo; it says a specific second, and each city renders that same second as a different wall-clock time. Timezones enter only at the display layer, which is why a timestamp stored once can be shown correctly to users in any zone. The same instant in ISO 8601 text form ends with a Z, and the ISO 8601 guide covers that format.

How do leap seconds affect the count?

Civil clocks occasionally insert an extra second to stay aligned with the Earth rotation, but POSIX time ignores them: it treats every day as exactly 86,400 seconds. The result is that an epoch timestamp is a count of ideal seconds rather than true astronomic time. The gap is small, corrects itself over years, and is irrelevant for almost every application. If you need to know about it at all, the rule is simply that the count skips the leap seconds.

What is the year 2038 problem?

The counter is a signed integer, and on many older systems it is 32 bits. That runs out at 2,147,483,647 seconds, which is 2038-01-19 03:14:07 UTC; one second later the value wraps to a negative number and reads as a date in 1901. Systems that store timestamps in 64-bit integers will not hit the wall for hundreds of billions of years. The operational risk is in embedded devices, old file formats and databases that never migrated, the same class of problem as the year 2000 rollover.

What happens before 1970?

Timestamps before the epoch are simply negative integers: -1 is one second before 1970, -86400 is the whole of 1969-12-31. Nothing in the format forbids them, and systems that need to record historical dates use them routinely. The only wrinkle is rendering: some libraries assume a positive value and mishandle negatives, so a date from 1960 stored as a timestamp should be tested in the tools that read it.

How do you read an epoch value?

The Unix Timestamp Converter accepts a number, detects whether it is seconds, milliseconds or nanoseconds, and shows the UTC and local readings side by side. For conversion in code, the patterns in the Unix timestamp guide cover JavaScript and Python. The one decision to keep in mind is the unit, because a value in milliseconds is one thousand times a seconds value and looks plausible in both.