Time zones, daylight saving, and Unix timestamps

Time bugs are some of the hardest to reproduce. A meeting invitation shows the wrong hour for half the attendees, a report double-counts one night in October, or a scheduled job skips a run in March. Nearly all of them come from mixing up three different things: an instant in time, a local wall-clock time, and the rules that connect the two.

Instants vs. wall-clock times

An instant is a single point on the global timeline, the same everywhere. “2026-09-21T14:42:54Z” is an instant: the Z means UTC. A wall-clock time such as “9:00 on Monday” means nothing on its own until you say where. 9:00 in Amsterdam and 9:00 in New York are six hours apart for most of the year.

The safe pattern for software is simple. Store and transmit instants in UTC, and convert to local time only when displaying to a person or when a rule is genuinely local, such as “the shop opens at 9:00 local time”.

Unix timestamps

A Unix timestamp counts the seconds since 1970-01-01T00:00:00Z, the Unix epoch, ignoring leap seconds. It has no time zone: the same number is the same instant everywhere, which makes it ideal for logs, databases, and APIs. With the Unix timestamp converter, 1790001774 becomes 2026-09-21T14:42:54Z.

Two details cause most timestamp bugs:

• Seconds vs. milliseconds. JavaScript’s Date.now() returns milliseconds (13 digits today). Unix tools, most databases, and JWT exp/iat claims use seconds (10 digits). Treating one as the other lands you in 1970 or in the year 58,000.
• The year 2038 problem. A signed 32-bit integer overflows at 2038-01-19T03:14:07Z. Modern systems use 64-bit timestamps, but old embedded devices, file formats, and database columns may not.

Time zones are rules, not offsets

“UTC+1” is an offset: a fixed difference from UTC. “Europe/Amsterdam” is a time zone: a set of rules that says the offset is +1 in winter, +2 in summer, and exactly when it switches. Rules change by political decision. Countries adopt or abandon daylight saving time, sometimes with only weeks of notice. They are published in the IANA time zone database, which your operating system and browser update regularly.

Abbreviations are ambiguous. IST can mean India, Ireland, or Israel, and CST is used in the US, China, and Cuba. Use IANA names such as America/Chicago in software and in any invitation that must be unambiguous.

Daylight saving time transitions

Twice a year, local clocks in many regions jump. In the EU, clocks go forward at 01:00 UTC on the last Sunday of March and back at 01:00 UTC on the last Sunday of October. The US changes on different dates: the second Sunday of March and the first Sunday of November. That creates two kinds of problem:

• Gaps: when clocks spring forward, a local time such as 02:30 does not exist that day. A job scheduled for 02:30 local time may be skipped or run at 03:30.
• Overlaps: when clocks fall back, 02:30 happens twice. A job may run twice, and hourly reports see one hour with double data.

The different EU and US dates also mean the gap between two cities changes for a few weeks each year. On 2026-03-28, 12:00 UTC was 13:00 in Amsterdam and 08:00 in New York, five hours apart. A day later, after Europe switched, it was 14:00 and 08:00, six hours apart. The time zone converter starts from a UTC instant for exactly this reason: an instant is never ambiguous, and each zone’s rules are applied for that exact moment.

Practical rules

1. Store instants as UTC timestamps or ISO 8601 strings with a Z or an explicit offset.
2. Store the user’s IANA time zone separately when you need their local time later, such as for recurring events or local business hours.
3. Schedule server jobs in UTC. Most cloud schedulers, including GitHub Actions and Cloudflare Workers cron triggers, only support UTC anyway.
4. Avoid scheduling local-time jobs between 01:00 and 03:00, where DST transitions happen in most regions.
5. For meetings, pick the time, convert it to UTC, and check the local date for every participant, since late afternoon in California is already the next day in Asia.
6. Use durations in fixed units for elapsed time. The duration calculator treats a day as exactly 24 hours, which is right for elapsed time but not for “the same time tomorrow” across a DST change.

For calendar questions that do not involve clocks at all, such as ages, deadlines, and working days, see the guide on counting days, business days, and ISO weeks.