Unix Timestamps Explained: Converting Epoch Time to a Date

A Unix timestamp is a way of representing a moment in time as a single number: the count of seconds that have elapsed since the first instant of 1 January 1970. So a timestamp like 1735689600 is not a random figure but a precise point in time, waiting to be translated into a human-readable date. The Timestamp Converter translates between epoch numbers and dates in your browser, and this article explains what these timestamps are and why computers use them.

If you have ever seen a ten-digit number where a date should be, in a log file, a database, an API response, you have met epoch time. Once you understand it, those numbers become perfectly readable.

Why computers count from 1970

Representing time as a single count of seconds from a fixed starting point solves a hard problem elegantly. Human calendars are messy, months of different lengths, leap years, time zones, daylight saving, and doing arithmetic with them directly is error-prone. A plain count of seconds sidesteps all of that: to find the duration between two moments you simply subtract one number from the other. The chosen starting point, midnight UTC on 1 January 1970, is called the Unix epoch, picked by the designers of the Unix operating system, and it became a near-universal standard across computing.

Seconds versus milliseconds

There is one detail that causes constant confusion: some systems count seconds since the epoch, while others count milliseconds. A seconds-based timestamp for a recent date is about ten digits long; a milliseconds-based one is about thirteen. Mixing them up throws your date off by a factor of a thousand, a timestamp interpreted in the wrong unit can land you decades or millennia away from the intended moment. JavaScript, for instance, works in milliseconds, while many other systems use seconds. When a converted date looks absurdly wrong, a seconds-versus-milliseconds mismatch is the first thing to check.

Timestamps and time zones

A Unix timestamp is inherently in UTC, it is an absolute count of seconds with no time zone attached. The same timestamp represents the same instant everywhere on Earth; what differs is how that instant is displayed as a local date and time. This is actually a feature: by storing an absolute moment and only applying a time zone when displaying it, systems avoid a whole class of bugs. When you convert a timestamp, you therefore choose which time zone to display it in, and the same epoch number can correctly show as, say, late evening in one zone and early morning in another.

Where you will meet epoch time

Unix timestamps are everywhere in software, precisely because they are so convenient for computers:

• Log files, which record when each event happened as an epoch number.
• Databases, which often store dates as timestamps for compact, sortable storage.
• API responses, where fields like created_at or expires are frequently epoch values.
• JWTs and tokens, whose expiry (exp) and issued-at (iat) claims are Unix timestamps.
• File metadata, which records creation and modification times this way.

Converting in both directions

Conversion goes both ways and both are useful. Turning a timestamp into a date makes a log or API response readable, you can see exactly when something happened. Turning a date into a timestamp lets you construct values to send to a system that expects epoch time, or to compare against stored timestamps. For working out the gap between two moments, subtracting their timestamps gives the difference in seconds directly, though a date difference calculator is friendlier for human-scale answers in days and years. For displaying a moment in another location, pair the converter with a time zone converter.

The year 2038 problem and how it is being fixed

Unix time has a famous quirk worth knowing about: the year 2038 problem. Many older systems store the timestamp as a signed 32-bit integer, which can only count up to about 2.1 billion seconds, a limit the clock will reach on 19 January 2038. At that instant, the counter would overflow and wrap around to a large negative number, throwing affected systems back to 1901 and potentially causing failures in anything that relies on the date. It is, in spirit, the same kind of counting-limit issue as the year 2000 problem, just with a different cause and deadline.

The fix is straightforward and already widespread: move to a 64-bit integer for the timestamp, which pushes the overflow point hundreds of billions of years into the future, far longer than the universe has existed. Modern operating systems and programming languages have largely made this switch, so most current software is unaffected. The lingering risk is in old embedded systems and legacy code that is hard to update. For everyday purposes the problem is a curiosity rather than a threat, but it is a useful illustration of a deeper truth about timestamps: they are just numbers with a fixed size, and like any counter they have limits. Understanding that a timestamp is a bounded integer, not an infinite quantity, is part of understanding what epoch time really is and why the transition to 64 bits mattered.

The practical takeaway for anyone working with timestamps is to be explicit about units and time zones at every boundary. When you store or send a timestamp, know whether it is in seconds or milliseconds and treat it as UTC; when you display one, apply the viewer's time zone deliberately rather than by accident. Following that discipline avoids the two classic timestamp bugs, the thousand-fold error from confusing seconds and milliseconds, and the off-by-hours error from forgetting a value is UTC, and lets epoch time do what it does best: represent an exact moment simply and unambiguously.

To sum up: a Unix timestamp is simply the number of seconds since the start of 1970 in UTC, a representation that makes time arithmetic easy and time zones tidy. Watch the seconds-versus-milliseconds distinction, remember that the number itself is time-zone-neutral until you display it, and you will be able to read those mysterious ten-digit numbers wherever they appear, and convert them to and from real dates whenever you need to.