Unix timestamps and time zones explained
Computers keep time as a single number: the count of seconds since a fixed moment. People read time as a date, an hour and a place. Almost every bug with dates happens in the translation between the two — a meeting an hour off after the clocks change, a date that shows as 1970, an export that is a day out. This guide covers what the number means, how to recognise its units, and why the same instant has a different local time in every time zone.
What a Unix timestamp counts
A Unix timestamp is the number of seconds that have passed since 1 January 1970 at 00:00:00 UTC, a moment known as the Unix epoch. At midday UTC on 24 September 2026 it was 1,790,251,200.
The number is the same everywhere on Earth at the same instant. It carries no time zone: the zone only appears when the number is turned into a date for a person to read. That is why timestamps are the safe way to store and exchange moments between systems, and local times are only for display.
Unix time also ignores leap seconds. Every day is counted as exactly 86,400 seconds, and when a leap second is added the clock simply repeats a second. For almost every purpose that is invisible, and leap seconds are on their way out: in 2022 the General Conference on Weights and Measures decided to stop adding them by 2035.
01 January 1970, 00:00:00 UTC: the epoch itself.179025120024 September 2026, 12:00:00 UTC.-8640031 December 1969: negative numbers count backwards.
Seconds or milliseconds?
The same moment is often written in two units. Unix tools, databases and most APIs use seconds; JavaScript, Java and many logging systems use milliseconds. For dates in this century the length gives it away: 10 digits are seconds, 13 digits are milliseconds.
Getting it wrong is easy to spot. A millisecond value read as seconds lands tens of thousands of years in the future; a second value read as milliseconds lands in January 1970. If a date shows up as 1970, the first thing to check is the unit.
The year 2038 problem
Many older systems store the timestamp as a signed 32-bit integer, whose largest value is 2,147,483,647. That second falls on 19 January 2038 at 03:14:07 UTC. One second later the number overflows and wraps round to 13 December 1901.
Modern operating systems, databases and languages use 64-bit time, which pushes the limit billions of years away. The risk sits in embedded devices, old file formats and database columns declared as 32-bit integers — which is why dates far in the future, such as the end of a 30-year loan, can fail today.
UTC, offsets and time zones
UTC, Coordinated Universal Time, is the reference every other time is measured against. It does not change with the seasons. GMT is often used as its everyday name; for anything but astronomy the two can be treated as the same.
A UTC offset says how far a local clock is ahead of or behind UTC: Lisbon in winter is UTC+0, Berlin UTC+1, São Paulo UTC−3, Tokyo UTC+9. Offsets are not always whole hours — India is UTC+5:30 and Nepal UTC+5:45 — and they run from UTC−12 to UTC+14.
A time zone is more than an offset. It is a place's full history of offsets and daylight-saving rules, recorded in the tz database under names such as Europe/Lisbon or America/Sao_Paulo. Software that converts past or future dates needs the zone, not just today's offset, because the rules change: Brazil, for example, abolished daylight saving time in 2019.
| Written as | What it means |
|---|---|
2026-09-24T12:00:00Z | ISO 8601 / RFC 3339 in UTC; the Z stands for UTC. |
2026-09-24T13:00:00+01:00 | The same instant, written with a local offset of UTC+1. |
2026-09-24 13:00 | A local time with no offset or zone — ambiguous until you know where it was written. |
1790251200 | The same instant as a Unix timestamp in seconds. |
Daylight saving time
Many countries move their clocks forward an hour in summer and back in winter, and they do not all do it on the same day. In the European Union the change happens at 01:00 UTC on the last Sunday of March and the last Sunday of October, at the same instant in every member state. The United States changes on the second Sunday of March and the first Sunday of November, at 2:00 local time. In the southern hemisphere the seasons are reversed, and many countries — Brazil and most of Asia and Africa among them — do not change at all.
So for a few weeks each spring and autumn, the gap between two cities is an hour different from usual. That is when recurring meetings drift, and why a scheduling tool needs the cities, not fixed offsets.
The changes also create local times that do not exist and times that happen twice. On the spring-forward night, 01:30 in Lisbon never happens; on the autumn night, 01:30 happens twice, once in summer time and once in winter time. A timestamp has neither problem, which is another reason to store instants as timestamps.
Frequently asked questions
Why does a date show as 1 January 1970?
Because the stored value was 0, empty, or a timestamp in seconds read as milliseconds. The epoch is what a date looks like when the number behind it is zero or close to it.
Is a Unix timestamp in UTC or in local time?
Neither: it is a count of seconds from a UTC starting point, and the same at every place on Earth. It only becomes a UTC or local time when it is displayed.
Why is my export one day off?
Usually a date without a time was treated as midnight UTC and then shown in a zone behind UTC, which turns it into the evening of the day before. Store dates that have no time of day as plain dates, not timestamps.
What does the Z at the end of a time mean?
It marks the time as UTC, the same as +00:00. The letter comes from the military name for the zone, “Zulu”.