How to Test Time Zone and Daylight Saving Time Bugs in Your Code

Time zone bugs have an unusually bad habit of passing every test suite and then failing in production on one particular date — because most tests unintentionally run against "today," and most days aren't anywhere near a DST transition or a time zone edge case. Testing this class of bug requires deliberately picking the dates that expose it, not just running the suite whenever it happens to run.

1. Don't Test Against "Now" — Pin the Clock

Any test whose outcome depends on the actual current date and time is only exercising whatever edge case happens to be true today, which is almost never a DST transition. Freeze or mock the system clock to a specific, deliberately chosen instant so the test is deterministic and actually exercises the case you intend — most languages have a standard tool for this (freezegun in Python, sinon.useFakeTimers() or jest.useFakeTimers() in JavaScript, or simply passing an explicit Date/datetime into the function under test instead of letting it call now() internally).

2. Test the Specific Dates DST Actually Transitions On

For any code that does date arithmetic across a DST-observing zone, write dedicated test cases for:

The "spring forward" date itself, where a local hour (e.g. 2:00am-2:59am in the US) doesn't exist at all that day — code that constructs a datetime from raw hour/minute values without validating it can silently produce a wrong or invalid result.
The "fall back" date, where a local hour occurs twice — code that assumes a given local time maps to exactly one instant will pick one of the two arbitrarily, which is a real bug if the two instants are an hour apart.
The day before and the day after a transition, to confirm your offset calculation shifts at the right boundary and not a day early or late.
A control date with no transition nearby, so you have a baseline confirming the non-DST-transition case still works.

Since DST transition dates move year to year and differ by country, hardcode the specific date under test (e.g. "2026-03-08" for the US spring transition) rather than trying to compute "the next DST transition" inside the test itself — the whole point is to exercise a known, fixed edge case reliably.

3. Test at Least One Non-Whole-Hour Offset

If your code assumes every time zone offset is a whole number of hours, it will pass every test written only against US or European zones and then fail the moment a user is in India (UTC+5:30) or Nepal (UTC+5:45). Include at least one 30- or 45-minute-offset zone in test fixtures specifically to catch integer-hour assumptions baked into the code.

4. Test a Zone That Never Observes DST at All

Alongside DST-observing zones, include a zone that never changes (Japan, most of China, Arizona in the US) in your test matrix. This catches the opposite bug: code that always applies a seasonal DST adjustment even to zones that never have one.

5. Don't Rely on the CI Server's Own Time Zone

A test suite that implicitly depends on the machine running it being in a particular time zone will behave differently on a developer's laptop than on a CI server (which is very often UTC) — and that inconsistency is itself a sign the code under test isn't handling zones explicitly enough. Explicitly set and assert the time zone your test is exercising rather than relying on whatever the environment happens to default to.

A Minimal Test Matrix

A reasonable minimum matrix per timezone-sensitive function: one zone with a whole-hour DST transition, one 30/45-minute-offset zone, one zone with no DST at all, the specific spring-forward date, the specific fall-back date, and a plain control date. That's usually enough to catch the overwhelming majority of real timezone bugs before they reach production — which, per our own Handling Timezones & UTC in JavaScript guide, cluster around exactly the same small set of root causes every time.

For the language-specific pitfalls this test matrix is designed to catch, see Handling Timezones & UTC in JavaScript and Time Zones and DST in Python. To sanity-check real DST transition dates for a specific place, use our DST Tracker.