Unix Timestamps and Timezones: The Confusion That Eats Your Week

Dates are the most innocently broken domain in software. Every developer thinks they understand time until a production bug surfaces on the last Sunday in March, or a user in Samoa reports that their analytics dashboard shows them tomorrow’s data.

This is a practical walkthrough of what a Unix timestamp actually is, how timezones interact with it, and the small set of rules that keep teams from shipping the same date bug every year.

What a Unix timestamp is

A Unix timestamp is a single number: seconds elapsed since 00:00:00 UTC on 1 January 1970, not counting leap seconds.

That’s it. It’s a moment in time, expressed as a count. No timezone is attached, because it’s always measured against UTC. At any given instant, there’s one correct Unix timestamp, and every machine on Earth should agree on it.

Example: as I write this, the Unix timestamp is 1,761,000,000 (roughly) — that’s April 21, 2026, 14:40 UTC. Converted to Tokyo time (UTC+9), it’s April 21, 23:40. To New York (UTC−4 during daylight saving), April 21, 10:40. Same moment, three different local-time representations of it.

The Unix timestamp is the universal reference. Everything else is a display layer.

Our Unix Timestamp Converter converts between the number and human-readable date in any timezone.

Seconds, milliseconds, microseconds

The “seconds since 1970” definition is the classical one. In practice, you’ll see three granularities:

• Seconds (10 digits): 1761000000 — traditional Unix time
• Milliseconds (13 digits): 1761000000000 — JavaScript’s Date.now()
• Microseconds (16 digits): 1761000000000000 — some databases, logging systems

If you ever see a timestamp you don’t recognize, count the digits. If it looks like it’s about now, a 10-digit number is seconds and a 13-digit number is milliseconds. Getting this wrong multiplies your date by 1000, which is usually obvious in testing — “the year 57,739” is a clue.

Timezones vs. offsets

This is the distinction that causes the most trouble. An offset is a fixed displacement from UTC, written like +05:30 or -08:00. A timezone is a rule: “Europe/London behaves like UTC+0 most of the year and UTC+1 during summer.”

+05:30              — offset, always the same
Asia/Kolkata        — timezone, always +05:30 (no DST)
Europe/London       — timezone, +00:00 in winter, +01:00 in summer
America/New_York    — timezone, -05:00 in winter, -04:00 in summer

Saving “Europe/London” as a user’s timezone is correct, because it encodes the rule. Saving “UTC+1” is wrong, because in six months the rule changes and the offset doesn’t match anymore.

This is why the IANA tz database (also called “Olson” or “tzdata”) has names like America/Los_Angeles rather than PST or UTC-8. The three-letter abbreviations are ambiguous (CST is both Central Standard Time in the US and China Standard Time, which are 14 hours apart), and the offset alone doesn’t know when the rule changes.

Our Timezone Converter uses IANA timezone names and knows the full rule set for each — so converting across the DST boundary works correctly.

Daylight saving time: the predictable disaster

Twice a year, most of the world’s DST-observing regions shift their clocks. When the clock “springs forward” in March (US) or the last Sunday of March (EU), an entire hour doesn’t exist locally. When the clock “falls back” in autumn, a one-hour range happens twice.

Consequences:

• Spring gap: setting an event for 02:30 on the day of the spring transition is invalid in most US timezones — that time doesn’t exist.
• Autumn duplication: 01:30 on the day of the autumn transition happens twice. “01:30 local time” is ambiguous for a range of several hours that day.
• DST doesn’t apply uniformly. The EU’s dates differ from the US. Arizona (mostly) doesn’t observe DST. Hawaii doesn’t. Many tropical regions don’t.

If you’re scheduling events in local time — recurring meetings, for example — store the timezone, not the UTC timestamp. A meeting at “9:00 AM Tokyo every weekday” stays at 9:00 Tokyo even as Tokyo doesn’t shift but the developer’s timezone does.

If you’re logging events — when a click happened, when a transaction occurred — store the UTC timestamp. The local-time representation is something you compute at display time, knowing the viewer’s timezone.

ISO 8601: the only datetime format that deserves trust

ISO 8601 is the international standard for representing dates and times. The canonical form looks like:

2026-04-21T14:40:00Z              ← Z = UTC (also written +00:00)
2026-04-21T14:40:00.123Z          ← milliseconds
2026-04-21T10:40:00-04:00         ← offset (New York, DST)
2026-04-21T09:40:00.000-05:00     ← one-second resolution is optional

It’s sortable as text, unambiguous, and parseable by essentially every datetime library. When in doubt, serialize dates to ISO 8601.

Formats to avoid in interchange:

• MM/DD/YYYY (American) vs. DD/MM/YYYY (European) — 02/03/2026 is February 3 or March 2 depending on the reader’s origin.
• Any format without a timezone — 2026-04-21 14:40:00 is useless without knowing what timezone the sender used.
• RFC 2822 format (Mon, 21 Apr 2026 14:40:00 GMT) — parseable but clunky, and locale-dependent for the weekday name.

The Date Formatter converts between ISO 8601 and various display formats without losing the underlying timestamp.

The rules that prevent date bugs

Store UTC. Display local.

This is the foundational rule. Your database should store UTC timestamps, always. When you show a date to a user, convert to their timezone at display time. A record created on March 12 at 11:50 PM Pacific should be stored as March 13 at 06:50 UTC. The UTC value is canonical.

Never do date math in local time.

“Add 24 hours” in local time might not get you to the same wall-clock time tomorrow — if you crossed a DST boundary, you’re off by an hour. “Add 24 hours” to a UTC timestamp always gets you to exactly 24 hours later, and then you convert to display.

Never parse a date string without an explicit timezone assumption.

new Date("2026-04-21 14:40:00") in JavaScript is interpreted as local time. In one user’s browser, that’s one moment; in another’s, a different moment. If you don’t know the timezone, your dates are wrong.

Store user-facing recurring events with a timezone, not a UTC instant.

“Monday at 9 AM New York time every week” is a rule that reuses the America/New_York timezone at each occurrence. Stored as a recurring UTC timestamp, it drifts by an hour at DST changes.

Why the Y2038 problem still matters a little

A signed 32-bit integer holding Unix seconds overflows at 2,147,483,647 seconds, which is 03:14:07 UTC on January 19, 2038. Any system still using 32-bit signed timestamps at that point will wrap into a negative number and think it’s 1901.

This used to be a major concern. Most modern systems have moved to 64-bit timestamps. A few embedded systems, legacy databases, and old file systems haven’t. If you maintain any code where time_t is still 32-bit, or where timestamps get packed into a 32-bit field, 2038 is a real problem.

The fix is to use 64-bit storage. The challenge is auditing every place a timestamp lives in an older system.

Working across timezones

A few practical patterns for teams working across regions:

• Have a default “reference” timezone for operations. Many companies use UTC even for internal scheduling; others use the headquarters timezone. Be explicit — “Thursday 9 AM” means nothing without a qualifier.
• Use tools that show relative + absolute. Slack’s time-zone-aware timestamps, Google Calendar’s local time conversion, or a tool like the World Clock for quickly checking multiple locations.
• Write dates with timezone labels. “March 15, 14:00 UTC” is unambiguous. “March 15, 2 PM” depends entirely on who’s reading.

The meta-lesson

Dates in software are not a domain where “good enough” holds up. Every ambiguity gets exercised eventually — by the last customer to file a bug, by the DST transition that happens next Sunday, by the international team member whose Monday is everyone else’s Sunday.

The good news is that the rules are small and the tools are mature. UTC in storage, IANA timezones for display rules, ISO 8601 for interchange. Follow those three and most of the date bugs that plague teams in their first year disappear.

The bad news is that every developer has to learn the rules the hard way at least once. This article is an attempt to shortcut that.