Unix Timestamp, ISO 8601 and Time Zones: Taming Dates in Code

What the Unix epoch is

Every computer needs one unambiguous way to mark a moment in time. The answer Unix landed on back in the 1970s — and that now drives almost everything: databases, APIs, logs, operating systems — is almost embarrassingly simple. Count the number of seconds that have passed since a fixed reference instant. That reference is called the epoch, and it is midnight on January 1, 1970, in the UTC time zone.

A Unix timestamp is just that count. The number 0 is exactly 1970-01-01 00:00:00 UTC. The number 1,000,000,000 (one billion seconds) landed on September 9, 2001. And the number running through systems at this very moment has ten digits, somewhere around 1.75 billion.

The big win is that the timestamp is a single integer: no time zone, no date format, no "which one is the day and which is the month." The instant "now" carries the same timestamp in Tokyo, in Texas, and on Mars. What changes from place to place is only how each clock chooses to display that number.

A worked example helps. A day has 86,400 seconds (24 × 60 × 60). Take the timestamp 90061. Notice that 90061 = 86,400 + 3,600 + 60 + 1 — that is, 1 day, 1 hour, 1 minute and 1 second after the epoch. So 90061 corresponds to 1970-01-02 01:01:01 UTC. That arithmetic of dividing by 86,400, then 3,600, then 60 is exactly what the Unix Timestamp Converter does for you in both directions — from raw number to readable date and back again.

Seconds vs milliseconds (the classic mix-up)

This is where the most common date bug lives. There are two worlds. Traditional Unix, plus languages like C, Python, PHP and Go, count the timestamp in seconds. JavaScript — where Date.now() and getTime() are the norm — returns the count in milliseconds. So the same instant can show up as 1719705600 (seconds) or 1719705600000 (milliseconds).

The accident happens when the two get crossed. In JavaScript, writing new Date(1719705600) reads the number as milliseconds and drops you twenty days past the epoch — January 1970, not 2024. What you wanted was new Date(1719705600000) or new Date(1719705600 * 1000). Going the other way, feeding milliseconds into a function that expects seconds flings you thousands of years into the future.

The fastest way to tell which unit a number is in: count the digits.

Rule of thumb: if the number is around 1.7 billion, it's seconds; if it's around 1.7 trillion, it's milliseconds. The ten-digit seconds count, by the way, holds until the year 2286 — it won't betray you any time soon. When in doubt, paste the number into the converter: if the date comes out as "1970" or as some absurd year far in the future, you got the unit wrong by a factor of a thousand.

ISO 8601: the format with no ambiguity

Write 03/04/2026 and half the planet reads "March 4" while the other half reads "April 3." That fight between mm/dd and dd/mm has broken integrations, delayed flights and scrambled spreadsheets. The ISO 8601 standard exists precisely to end it.

The rule is to write from largest to smallest — year, month, day, time — always with leading zeros:

• 2026-06-30 — date only.
• 2026-06-30T14:30:00Z — date and time. The T separates the date from the time; the Z (read "Zulu") means UTC, offset zero.
• 2026-06-30T11:30:00-03:00 — the same instant, written in Brasília time (UTC−3). Notice: 11:30 in Brasília plus 3 hours equals 14:30 in UTC.

On top of removing ambiguity, the format has a precious bonus: because it is "big-endian" (most significant component first), sorting these strings alphabetically already puts them in chronological order. That is worth its weight in gold for filenames, database keys and logs. The profile most used in APIs is RFC 3339, a slightly stricter version of ISO 8601 — it's what you see in nearly every modern back-end JSON.

When what you have is a date in one country's format and you need it in ISO (or the reverse), the Date Format Converter bridges between dd/mm/yyyy, mm/dd/yyyy, ISO 8601 and other patterns without making you memorize format masks.

Weeks have a standard too

ISO 8601 goes beyond the date: it defines how to number the weeks of the year. The week starts on Monday, and week 1 is the one containing the year's first Thursday (equivalently, the one containing January 4). That is why the first days of January sometimes belong to week 52 or 53 of the previous year. It's a convention that surprises anyone who hasn't met it — financial reports and manufacturing systems run on it. To find which ISO week a date falls into, use the ISO Week Number tool.

UTC, time zones and the daylight-saving nightmare

UTC (Coordinated Universal Time) is the world reference, the ruler from which every time zone is an offset. But you have to separate two ideas that daily life blurs together: an offset is not the same thing as a time zone.

An offset is a fixed number, like −03:00. A time zone is a region whose rules change over time — for example, America/Sao_Paulo or America/New_York. The distinction is crucial. Brazil abolished daylight saving time in 2019, so today São Paulo sits at UTC−3 all year. But before that, in summer the clocks shifted to UTC−2. A fixed offset can't capture that history; the zone name can.

That is where the daylight-saving nightmare comes from for programmers. When the clock "springs forward," there is a local time that simply does not exist (the clock jumps from 1:59 to 3:00). When it "falls back," there is a local time that happens twice — and now "1:30 AM" on that day is ambiguous. Scheduling a reminder or computing a difference across those edges is an endless source of bugs.

The best practice that solves almost all of it fits in three lines:

1. Always store the instant in UTC (or as a Unix timestamp, which is UTC by definition).
2. Convert to local time only when displaying it to a user.
3. For the zone, use the IANA database names (America/Sao_Paulo, Europe/London), never fixed offsets — because daylight-saving rules change by political decision and the IANA database is updated to keep up.

The year 2038 bug

The timestamp is a number, and numbers need room to be stored. Many older systems keep Unix time in a signed 32-bit integer. The largest value that type can hold is 2,147,483,647 (that is, 2³¹ − 1). Convert it and that many seconds runs out at exactly 03:14:07 UTC on January 19, 2038.

One second later, the counter "overflows" and goes negative, throwing the date back to December 13, 1901. It's the same flavor of problem as the millennium bug (Y2K), with a different cause: there it was the two-digit year; here it's the limit of a 32-bit integer.

The fix has been underway for years and is straightforward: use 64-bit integers, which push the limit out to something like 292 billion years — plenty of headroom. Modern operating systems, languages and databases already do this. The real risk sits in old embedded systems, legacy file formats and database columns created long ago with the 32-bit type. If you maintain anything like that, 2038 is a genuine deadline — just far enough away to be planned for calmly.

Frequently asked questions

Does a Unix timestamp change when I switch time zones?

No. The timestamp represents an absolute instant and is always referenced to UTC. Changing time zone only changes the date and time that are displayed, never the underlying number. That's exactly why it's so popular for recording "when" something happened: two servers on different continents log the same event with the same timestamp.

How do I know if a timestamp is in seconds or milliseconds?

Count the digits. For current dates, ten digits are seconds (around 1.7 billion) and thirteen are milliseconds (around 1.7 trillion). If you convert and the date lands in 1970 or in some impossible future year, you got the unit wrong by a factor of a thousand.

Are ISO 8601 and RFC 3339 the same thing?

Almost. RFC 3339 is a stricter profile of ISO 8601, designed for the internet: it requires the T separator, requires the time-zone offset (Z or ±hh:mm), and forbids some exotic forms ISO permits. In practice, if you write 2026-06-30T14:30:00Z, it's valid under both.

What does the "Z" at the end of a date mean?

It's the zero offset — that is, UTC. It comes from the military naming of time zones, where UTC is the "Zulu" zone. 2026-06-30T14:30:00Z is identical to 2026-06-30T14:30:00+00:00.

Will the 2038 bug take down the internet?

Not in any catastrophic sense. The overwhelming majority of systems in use have already moved to 64-bit integers. The concern is with old embedded hardware and legacy databases that still store time in 32 bits — those need to be identified and updated before January 2038.