Tool
DST Ambiguity Checker
Find every DST transition in your city list over the next 12 months, and the exact wallclock hours that are non-existent or duplicated.
What makes this different
The explicit "non-existent hour" and "duplicated hour" callouts are the differentiator. Most DST tables only show the date of the switch; this one tells you which local clock hour is at risk, so you can grep your logs for that hour after the transition.
How to use it
- Pick the cities you care about.
- Read the calendar: each entry shows the date, the offset before/after, and which local hour is non-existent (spring forward) or duplicated (fall back).
Software that records wallclock times can record timestamps that do not exist or that occur twice, and not know which is which. This tool scans the next 12 months for every DST transition in your city list, and reports the exact wallclock hours affected. Useful for audit, for tests, and for writing the changelog entry when your service is "off by an hour" for a few hours.
Frequently asked questions
What is a "non-existent" hour?
In spring-forward, the local clock skips one hour (typically 02:00 becomes 03:00). Wallclock times in the gap (e.g. 02:30) never occur locally that day.
What is a "duplicated" hour?
In fall-back, the local clock repeats one hour (typically 02:00 occurs twice). Wallclock times in that hour occur twice on the same day.
How do I store timestamps during the gap?
Most databases store the UTC instant, not the wallclock. If you must store wallclock, mark it with the UTC offset so the duplicated hour is disambiguated.