Unix Time Explained: Epoch Seconds, Milliseconds and 2038

A single counter that started in 1970

Unix time, also called epoch time or a Unix timestamp, is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970. That starting instant is known as the Unix epoch. Instead of storing a year, month, day, hour, minute and second separately, a system stores one integer that keeps counting upward.

For example, midnight UTC on 23 October 2026 is 1792713600. A day always contains 86,400 seconds in Unix time, so dividing that value by 86,400 gives exactly 20,749, which is the number of whole days since the epoch. Moments before 1970 are simply negative: one second before the epoch, 23:59:59 UTC on 31 December 1969, is -1.

The appeal is that time becomes ordinary arithmetic. The gap between two events is a subtraction, sorting is a numeric sort, and adding a week means adding 604,800. That is why operating systems, databases, programming languages and web APIs rely on it so heavily.

One subtlety: Unix time ignores leap seconds. Every day is treated as exactly 86,400 seconds long, so the count is not a perfectly literal tally of elapsed SI seconds. For converting timestamps to calendar dates this almost never matters, but it explains why precise scientific timekeeping uses other scales.

• 0 = 1970-01-01 00:00:00 UTC
• 1000000000 = 2001-09-09 01:46:40 UTC
• 1700000000 = 2023-11-14 22:13:20 UTC
• 1792713600 = 2026-10-23 00:00:00 UTC

Seconds or milliseconds? Count the digits

Not every system uses the same unit. JavaScript's Date.now() returns milliseconds, while many server-side functions, command-line tools and APIs use seconds. The same instant is 1792713600 in seconds and 1792713600000 in milliseconds, a factor of 1,000 apart.

The quickest check is the number of digits. Any date between 9 September 2001 and 20 November 2286 has a 10-digit value in seconds and a 13-digit value in milliseconds. If you are dealing with present-day data, 10 digits almost certainly means seconds and 13 digits means milliseconds. Some systems go further and record microseconds (16 digits) or nanoseconds (19 digits), so anything longer deserves a look at the documentation.

Getting the unit wrong produces results that are wildly off rather than slightly off. Reading the seconds value 1792713600 as milliseconds lands on 21 January 1970 at 09:12:57.6 UTC, only a few weeks after the epoch. Reading the millisecond value as seconds points to a year beyond 50,000. If a converted date is suspiciously close to 1970 or absurdly far in the future, the unit is the first thing to check.

Time zones only matter when you display the value

A Unix timestamp has no time zone. The same instant produces the same number whether it is recorded in London, New York or Tokyo. Time zones enter the picture only when you turn the number into a human-readable date, or when you turn a local date back into a number.

Take 1792713600 again. In UTC it is midnight on 23 October 2026. In New York, which is on daylight saving time (UTC-4) on that date, it is 8:00 p.m. on 22 October. In Tokyo (UTC+9, no daylight saving) it is 9:00 a.m. on 23 October. The number did not change; only the way it was rendered did.

The reverse direction is where bugs usually creep in. Midnight on 23 October 2026 in Tokyo is 15:00 UTC on 22 October, which is 1792681200, exactly 32,400 seconds (nine hours) earlier than midnight UTC. If a script converts a date-only value such as 2026-10-23 without stating which midnight it means, daily reports can quietly shift records into the wrong day. Decide on one reference zone, usually UTC, for storage and aggregation, and convert to local time only at the edges where people read the data.

Zones with daylight saving time add another wrinkle: their offset from UTC changes during the year, so a fixed number of hours cannot be applied blindly. The Unix value itself is unaffected, which is one more reason to store timestamps in UTC.

Reading timestamps in logs and APIs

A typical API response might include a field such as created: 1700000000. Converted, that is 22:13:20 UTC on 14 November 2023. Token and cache expiry fields work the same way: if a token was issued at 1792681200 and expires at 1792767600, the difference is 86,400 seconds, so it is valid for exactly one day. Dividing a difference by 3,600 gives hours and by 86,400 gives days.

A practical routine for any unfamiliar timestamp is: check the digit count to determine the unit, decide which time zone you want to see, then convert. The Unix Timestamp to Date converter on this site accepts both seconds and milliseconds and shows the result in UTC as well as UTC+9, alongside an ISO 8601 string. Going the other way, the Date to Unix Timestamp converter takes a date and a time (seconds optional), lets you say whether you typed it in UTC or UTC+9, and returns the value in seconds and milliseconds.

ISO 8601 strings such as 2026-10-22T15:00:00.000Z are a useful companion format. The trailing Z means UTC, and because the format sorts correctly as text, it is often used in logs that humans read while the underlying storage stays numeric.

• 1 minute = 60 seconds; 1 hour = 3,600; 1 day = 86,400; 1 week = 604,800
• Seconds to milliseconds: multiply by 1,000
• UTC+9 midnight is 32,400 seconds before UTC midnight of the same calendar date

The year 2038 problem

Many older systems stored Unix time as a signed 32-bit integer. The largest value that type can hold is 2,147,483,647, which corresponds to 03:14:07 UTC on 19 January 2038. One second later the counter can overflow and wrap around to -2,147,483,648, which represents 20:45:52 UTC on 13 December 1901. Software relying on that value could suddenly believe it is more than a century in the past, breaking expiry checks, scheduling and sorting.

Modern operating systems, databases and languages generally use 64-bit integers for time, which pushes the limit roughly 292 billion years into the future. The risk lies in what was left behind: embedded devices, old file formats, legacy database columns and binary protocols that still reserve only 32 bits for a timestamp.

If you maintain software that stores future dates, such as loan maturities, certificate expiry or long-term subscriptions, it is worth testing a date after January 2038 now rather than waiting. A quick conversion of a date like 2040-01-01 into Unix time and back is an easy first check that your storage and code paths handle values above 2,147,483,647.