How Daylight Saving Time Affects Unix Timestamps

#Unix time does not jump; the wall clock does

Unix timestamp is a single point in time. Daylight savings time changes the name of that moment on a local clock in an area.

That difference is the whole subject in one sentence.

A clock can jump forward in a spring transition, creating a gap in local times that do not occur. It can go backward and repeat a block of local time on an autumn transition. Both are part of the ongoing timeline of the UTC.

Direction	Local clock example	Mapping from local time to an instant
Spring forward	01:59:59 → 03:00:00	times in the gap have no match
Fall back	01:59:59 → 01:00:00	times in the overlap can have two matches

#The direction of conversion determines the risk

If you have a timezone database, then converting an instant to local time is deterministic:

instant + IANA timezone → one local date, time, and offset

The reverse direction can be ambiguous:

local date and time + IANA timezone → zero, one, or two instants

This is why “store UTC” is useful but incomplete advice. UTC is a good way to describe something that has already happened. A future event defined by civil time, such as “open the store at 09:00 every weekday in New York,” also needs the timezone whose future rules determine the instant.

#A spring gap creates times that never happen

In America/New_York, the current US rule moves the clock from 02:00 to 03:00 on the second Sunday in March. On March 8, 2026, the request below has no exact match:

2026-03-08 02:30:00 America/New_York

A library or scheduler must choose what to do. Common policies include:

• reject the input and ask for a valid time
• shift it forward by the size of the gap
• choose the first valid instant after the transition
• apply a compatibility behavior inherited from an older API

None of this is quite right. A medical appointment form might deny the time. nightly maintenance job could be expedited. It is in the product contract, not some library default that no one's read.

#A fall overlap creates two valid instants

On November 1, 2026, 01:30 occurs twice in New York:

2026-11-01T01:30:00-04:00 = 2026-11-01T05:30:00Z
2026-11-01T01:30:00-05:00 = 2026-11-01T06:30:00Z

The wall-clock text is the same, but the instants are 1 hour apart. They are defined by an explicit offset. An IANA timezone on its own tells you only that both are possible; a disambiguation policy picks one.

That overlap often causes jobs to be duplicated, logs to be ordered incorrectly, and duration calculations to add an hour with no warning.

#An offset and a timezone are not substitutes

An offset such as -05:00 describes one relationship to UTC. An IANA timezone such as America/New_York describes a history and a set of transition rules.

Value	What it answers	What it cannot answer
Unix timestamp	Which instant?	Which local scheduling rule?
UTC offset	How far from UTC at this instant?	What will the offset be later?
IANA timezone	Which regional rules apply?	Which occurrence of an overlap without a policy?
Abbreviation	A human label in context	A portable, unambiguous rule set

The IANA Time Zone Database changes as governments change civil-time rules. At the time of this article, IANA lists release 2026c; the version number itself is a reminder that timezone data is a dependency that needs updates.

#Store different kinds of events differently

Choose the model from the user's intent.

#Events that already happened

Store an instant, often as a database value with time zone or a well-documented Unix unit. Only keep the original zone or offset separate where it matters for audit or display.

Examples include payment captures, log entries, sensor readings, and message delivery.

#One future appointment in a known zone

If the input was in a gap or overlap, use the policy used. Keep the local date and time, the IANA timezone, the selected offset or resolved instant. Determine if modifications to the tzdb should recalc the instant or preserve the original booking.

#Recurring civil-time events

Store the recurrence rule, local clock time, and IANA timezone. Generate each occurrence with current timezone rules. Saving only the first UTC instant and adding fixed 24-hour periods will move the local time when DST changes.

#Exact elapsed-time processes

Use instants and durations. A timeout of 24 elapsed hours is not the same requirement as “same local time tomorrow.” One survives a DST transition as 24 hours; the other may span 23 or 25 elapsed hours.

#Format an instant in a timezone with JavaScript

Intl.DateTimeFormat converts an existing instant for display. It does not create an instant from an ambiguous local time.

const instant = new Date("2026-11-01T05:30:00Z");

const formatter = new Intl.DateTimeFormat("en-US", {
  timeZone: "America/New_York",
  dateStyle: "medium",
  timeStyle: "long",
});

console.log(formatter.format(instant));

For new code with Temporal support, make the ambiguity policy explicit:

const fields = {
  timeZone: "America/New_York",
  year: 2026,
  month: 11,
  day: 1,
  hour: 1,
  minute: 30,
};

const earlier = Temporal.ZonedDateTime.from(fields, {
  disambiguation: "earlier",
});

const later = Temporal.ZonedDateTime.from(fields, {
  disambiguation: "later",
});

console.log(earlier.epochNanoseconds !== later.epochNanoseconds);
// true

Use disambiguation: "reject" when silently choosing either occurrence would violate the product's contract.

#Schedulers need a documented transition policy

“Runs every day at 02:30” is underspecified in a zone with clock changes. Before trusting a scheduler, answer these questions:

1. Is the schedule defined in UTC or a named timezone?
2. What happens when the requested local time is inside a gap?
3. Does an overlap trigger the job once or twice?
4. Which tzdb version supplies the rules?
5. Are missed jobs replayed after downtime?
6. Is idempotency enforced if two invocations occur?

If you are scheduling on UTC this avoids the DST transitions, but it does affect the local time of execution when the offset of the zone changes. Some infrastructure jobs are like that, but wrong for lots of human schedules.

#Test transitions instead of testing a random Tuesday

A DST test suite should cover the boundary, not just a date in winter and a date in summer.

• the instant immediately before and after a forward transition
• a local time inside the spring gap
• both occurrences inside the fall overlap
• a recurring local event spanning both transitions
• a duration measured on the instant timeline across a transition
• behavior after updating the timezone database
• a zone without DST, as a control case

Do not change the real clock of the machine in a regular unit test. Provide explicit instants or add a clock to make the tests deterministic and safe for parallel execution.

#The reliable rule

Use an instant to record when. Use an IANA timezone and local fields to preserve what the clock should say. Require a policy when local input may map to 0 or 2 instants.

That model remains correct even when a legislature changes the dates. Hard-coded offset tables do not.

#Related reading

• Unix Time to Date
• Unix Timestamp Formats
• Leap Seconds Explained
• Year 2038 Problem
• Common Unix Timestamp Bugs