Unix Timestamps Explained: Time Zones, Milliseconds and the Year 2038
What a Unix timestamp is, how to convert it, why time zones and daylight saving cause bugs, seconds vs milliseconds, and the year 2038 problem.
Dates are deceptively hard in software. Time zones, daylight saving time, leap years and date formats that differ by country cause an endless stream of bugs. The Unix timestamp is the industry’s favourite way to avoid many of them, as long as you understand what it is and what it is not.
What a Unix timestamp is
A Unix timestamp is the number of seconds that have passed since 1 January 1970 at 00:00:00 UTC, a moment called the Unix epoch. At the time of writing, in late 2026, it is around 1.79 billion. The same instant has the same timestamp everywhere on Earth: a user in Tokyo and one in New York who click at the same moment produce the same number.
That is its superpower. Comparing, sorting and calculating differences between timestamps is simple arithmetic, with no time zones involved. The timestamp converter turns any value into a readable date and back.
Seconds or milliseconds?
Classic Unix systems, PHP, Python’s time.time() and most databases use seconds, which gives a 10-digit number today. JavaScript’s Date.now(), Java and many APIs use milliseconds, a 13-digit number. Mixing them up is a classic bug: a date in 1970 means you treated milliseconds as seconds the wrong way round; a date thousands of years in the future means the opposite. Our converter detects the unit from the number of digits.
Time zones: store UTC, display local
A timestamp has no time zone; it is always UTC. Time zones only matter when showing it to people. The golden rule for applications:
- Store instants as UTC (a timestamp or an ISO 8601 string ending in
Z). - Convert to the user’s local time zone only for display.
- Store the user’s time zone name, such as
Europe/Berlin, separately if you need it, not a fixed offset like+01:00, because offsets change with daylight saving time.
Daylight saving time traps
Once a year in many countries, local time jumps forward an hour, so a time like 02:30 does not exist that night. Once a year it falls back, so 01:30 happens twice. “Add one day” is not always “add 86,400 seconds” in local time: on those days a local day has 23 or 25 hours. Scheduling a daily job at a fixed local time, or calculating “the same time tomorrow”, must use a proper time zone library, not raw arithmetic.
When not to use a timestamp
Timestamps describe instants. Some things are not instants:
- Birthdays and holidays are calendar dates. Your birthday is 14 March wherever you are; storing it as midnight UTC can display it as 13 March for users west of Greenwich.
- Future appointments in local time, such as “9:00 at the dentist in Paris”, should be stored as local time plus the time zone name, because the government may change the time zone rules before the appointment.
Leap seconds
Unix time pretends every day has exactly 86,400 seconds and ignores leap seconds. When a leap second is inserted, Unix time repeats or smears a second. For almost all applications this does not matter, and international timekeeping bodies have decided to stop adding leap seconds by 2035.
The year 2038 problem
Many older systems store timestamps as signed 32-bit integers, which can count up to 2,147,483,647. That limit is reached on 19 January 2038 at 03:14:07 UTC. One second later, the number overflows to a large negative value, which old software would interpret as December 1901.
Modern operating systems and languages use 64-bit timestamps, which will last for about 292 billion years. The risk is in embedded devices, old databases, file formats and code with 32-bit fields that nobody has looked at in years. If you maintain such systems, now is a good time to check.
ISO 8601: the readable alternative
When people need to read dates in logs, APIs or JSON, use ISO 8601: 2026-10-12T08:30:00Z. It sorts correctly as text, is unambiguous across countries, and is understood by every programming language. Avoid formats like 03/04/2026, which means 3 April in Europe and 4 March in the US.
Our take
Use Unix timestamps or UTC ISO 8601 strings for anything that happened at a specific moment, keep time zones for display, and treat calendar dates as dates. Most date bugs we have debugged came from violating exactly one of those three rules.