Unix timestamps explained: seconds, milliseconds and the year 2038

What the number means

A Unix timestamp (or epoch time) counts the seconds that have passed since the Unix epoch: 00:00:00 UTC on 1 January 1970. Timestamp 0 is that exact moment; 1,000,000,000 is 9 September 2001 at 01:46:40 UTC; 1,700,000,000 is 14 November 2023 at 22:13:20 UTC. For 3 October 2026 at 00:00:00 UTC, the value is 1,790,985,600.

POSIX, the standard behind it, defines the value as one that approximates the number of seconds elapsed since the Epoch, with every day accounted for as exactly 86,400 seconds. That last detail means leap seconds are not counted: a timestamp is a tidy count of days times 86,400 plus the seconds into the day, which is what makes date arithmetic with it so easy.

Because it is counted from a fixed moment in UTC, a timestamp has no time zone. 1700000000 is the same instant in Madrid, New York and Tokyo; only the way it is displayed changes. That is the main reason systems store timestamps and convert to local time at the edge.

Seconds or milliseconds? Count the digits

The classic mistake. Different systems use different units:

• Seconds (10 digits at the moment): Unix and Linux tools, most databases and APIs, Python's time.time() (as a decimal), PHP's time().
• Milliseconds (13 digits): JavaScript's Date.now() and new Date(ms), Java's System.currentTimeMillis().

Mix them up and the date is wildly wrong. In JavaScript, new Date(1700000000) reads the number as milliseconds and gives 20 January 1970, whereas new Date(1700000000 * 1000) gives the intended 14 November 2023. Going the other way, treating a 13-digit millisecond value as seconds lands you thousands of years in the future. A quick rule for today's dates: 10 digits is seconds, 13 digits is milliseconds. The timestamp converter recognises both and shows the date in UTC and in your local time.

Timestamps and time zones

A timestamp is unambiguous; the text you write around it is not. If a form says "2026-10-25 02:30" with no offset, which instant is it? In Europe, on the night the clocks go back, 02:30 happens twice. When you need to exchange a time as text, use ISO 8601 with an offset or a Z for UTC, such as 2026-10-03T00:00:00Z or 2026-10-03T02:00:00+02:00. The ISO 8601 converter turns a timestamp or a local date into that format. And when you want to see what time it is in another place at the same instant, the time zone converter handles the offsets and daylight saving rules for you.

The year 2038 problem

If a system stores the timestamp as a signed 32-bit integer, the largest value it can hold is 2,147,483,647. That is 19 January 2038 at 03:14:07 UTC. One second later the counter overflows, and it wraps to a large negative number, which a naive system reads as a date in December 1901. That is the "Year 2038 problem", the Unix equivalent of Y2K.

Most modern systems have moved to 64-bit timestamps, which will not overflow for about 292 billion years, so a laptop or phone is not at risk. The ones that can be are old embedded devices, file formats or database columns that still use 32 bits. An unsigned 32-bit value pushes the limit to 7 February 2106, but you lose the ability to represent dates before 1970. If you design a schema today, use a 64-bit integer or a proper timestamp type.

Dates before 1970 and other edge cases

• Negative values are dates before the epoch: -1 is 23:59:59 UTC on 31 December 1969. POSIX leaves the relationship undefined for years before 1970, but most modern software handles negative values fine.
• Leap seconds are ignored, as explained above. In practice a system clock either repeats a second or "smears" it; the timestamp never shows 23:59:60.
• Fractions of a second are written as decimals (1700000000.123) or as milliseconds or microseconds with more digits.

Handy conversions

• One day is 86,400 seconds; one week is 604,800.
• To add 30 days to a timestamp in seconds, add 30 × 86,400 = 2,592,000. Be careful: that is exactly 30 days of 24 hours, not "one calendar month", and it is not "the same local time" if a daylight saving change falls in between.
• To go from milliseconds to seconds, divide by 1,000; to go the other way, multiply.

To see how daylight saving affects dates, read when the clocks change; and for the week number of a date, how ISO week numbers work.

Sources and further reading

• The Open Group (POSIX): Seconds Since the Epoch
• MDN: Date (JavaScript time values are milliseconds since the epoch)
• Wikipedia: Year 2038 problem

Figures checked on 3 October 2026.