Unix Timestamps and the Year 2038 Problem: Converting Epoch Seconds to Dates
October 29, 2026
Computers often store time as a single number: the count of seconds that have passed since the Unix epoch, 00:00:00 UTC on January 1, 1970, not counting leap seconds. This Unix timestamp is simple, compact, unambiguous across time zones, and easy to sort and subtract. The timestamp 1,000,000,000 corresponds to September 9, 2001 at 01:46:40 UTC, and 1,700,000,000 to November 14, 2023 at 22:13:20 UTC.
Many systems also use milliseconds since the epoch (a 13-digit number today) instead of seconds (10 digits). If a timestamp has 13 digits, divide by 1,000 to get seconds.
Skip the math and get your answer instantly:
Open the Date Calculator →Converting Timestamps
To convert a timestamp to a date by hand, divide by 86,400 (seconds per day) to get days since 1970-01-01, then count forward through the years, using 365 or 366 days. For 1,800,000,000: 1,800,000,000 ÷ 86,400 = 20,833.33 days, which is 57 years 15 days and 8 hours: January 15, 2027, 08:00 UTC. Spreadsheets convert with =A1/86400 + DATE(1970,1,1). Programming languages have built-in functions. To get the timestamp for a date, count the days since 1970 and multiply by 86,400.
Time zones affect only the display; the timestamp is always in UTC. The same timestamp is the same instant everywhere.
| Timestamp (seconds) | Date and time (UTC) | Note |
|---|---|---|
| 0 | 1970-01-01 00:00:00 | The epoch |
| 1,000,000,000 | 2001-09-09 01:46:40 | The billennium |
| 1,700,000,000 | 2023-11-14 22:13:20 | Recent round number |
| 1,800,000,000 | 2027-01-15 08:00:00 | Upcoming |
| 2,000,000,000 | 2033-05-18 03:33:20 | Future |
| 2,147,483,647 | 2038-01-19 03:14:07 | 32-bit signed limit |
The Year 2038 Problem
Older systems stored the timestamp as a signed 32-bit integer, whose maximum value is 2³¹ − 1 = 2,147,483,647. One second after 03:14:07 UTC on January 19, 2038, the counter overflows and wraps to −2,147,483,648, which represents December 13, 1901. Software that still uses 32-bit time could then see dates jump back to 1901, causing failures in calculations, certificates, schedules, and embedded systems. This is similar to the Y2K problem but with binary instead of decimal. Most modern operating systems and languages use 64-bit time, which will not overflow for about 292 billion years, but legacy systems, embedded devices, file formats, and databases with 32-bit fields need attention.
An unsigned 32-bit counter would last until February 7, 2106.
Leap Seconds and Precision
Unix time ignores leap seconds: each day has exactly 86,400 seconds, and the clock is adjusted when a leap second is inserted, so the same timestamp can repeat or be smoothed by systems. For most applications this is irrelevant, but for high-precision scientific timing, GPS time, TAI, and UTC differ by a few seconds. Daylight saving time changes do not affect the timestamp, which is one reason to store times in UTC.
Practical Tips
Store timestamps in UTC as integers or as ISO 8601 strings, and convert for display. Check whether an API returns seconds or milliseconds. When computing durations, subtract timestamps: 3,600 seconds is an hour. Avoid 32-bit fields for dates that extend past 2038, such as 30-year mortgage maturity dates or long-term expiration dates. Test software with dates after January 19, 2038.
Frequently Asked Questions
What is a Unix timestamp?
The number of seconds since January 1, 1970 at 00:00:00 UTC.
What happens on January 19, 2038?
Signed 32-bit Unix time overflows, which can cause failures in legacy systems.
How do I tell seconds from milliseconds?
A 10-digit timestamp is seconds; a 13-digit one is milliseconds.
Does the timestamp depend on time zone?
No. It is always UTC, and zones only affect display.
How do I convert a timestamp in Excel?
Use =A1/86400 + DATE(1970,1,1) and format as a date and time.