How Should You Test Daylight-Saving Boundaries?
From the earlier reference collection. Read the current software blog.
Test local clock transitions with explicit zones and distinguish elapsed duration from wall-clock labels.
Name the time zone in the test
A daylight-saving test should not depend on the machine running it. Choose an explicit named timezone and dates when its clocks move forward and backward. Avoid relying on the developer's local zone or a fixed UTC offset: offsets alone do not encode the historical clock-change rules associated with a region.
For each transition, create timestamps on both sides of the boundary and record whether the input represents an instant, a local wall-clock reading, or a schedule label. Those are different kinds of values. A test becomes ambiguous if it treats them as interchangeable.
Test elapsed time across the spring change
When clocks move forward, some local times do not occur. Choose two valid instants around the jump and calculate their elapsed duration using timezone-aware instants. For example, if one timestamp is just before the local clock advances and another is just after, the wall-clock labels may look farther apart than the actual elapsed interval. Assert the duration from the instants, not by subtracting the displayed hour and minute fields.
Also test how the application handles a user-entered local time inside the skipped interval. The intended behavior might be a validation error or a defined adjustment, but it should be explicit and tested rather than left to a library default.
Test the repeated hour in autumn
When clocks move back, a local time can occur twice. Construct both occurrences as distinct instants and confirm that the system can distinguish them when the application needs to. A useful assertion checks that the instants differ while their displayed local clock values match. This catches code that stores only a date and clock time where an unambiguous instant is required.
If the application accepts local time input, define how a user selects between the two occurrences, or how the system resolves ambiguity. Test that choice and make the resulting instant visible in diagnostics.
Keep duration and display assertions separate
Use one test for elapsed duration and another for formatted local display. The first verifies timeline arithmetic; the second verifies labels and timezone conversion. Fix the clock or inject a known instant if application behavior depends on “now.”
Finally, make expected outcomes independent of the host timezone database settings where practical, while using a real named zone in the behavior under test. Clear transition tests explain which clock changed, what duration should be measured, and how ambiguous local readings are resolved.