Time zone and DST debugger
Pick a time zone and a local date and time. The result says what instant that is in UTC, or that it happens twice, or that it never happens because the clocks skipped it; lists the clock changes in that year; shows what a job "every day at that time" does across the year; and gives the .NET and SQL Server calls that produce the same answers. It uses the time zone data in your browser.
Result
| Reading | Offset | UTC | ISO 8601 | In the second zone |
|---|
In code
.NET 6 and later SQL Server 2016 and later JavaScript Clock changes
| Instant (UTC) | Local clocks | Offset |
|---|
A job every day at this local time
| Date | Runs at | Offset | Note |
|---|
The bugs this catches
- Local time stored without its offset
- A DateTime with Kind Unspecified, or a SQL datetime, is a wall-clock reading with no zone. Once a year it is ambiguous and once a year it does not exist. Store UTC or datetimeoffset; convert at the edges.
- "Every day at 09:00"
- A daily job defined in local time runs at a different UTC time for half the year, and on two days a year the local time is skipped or repeated. Define the schedule in the zone it belongs to and let the scheduler do the conversion, or schedule in UTC and accept that it moves locally.
- Adding 24 hours to get tomorrow
- On the day the clocks change, tomorrow at the same local time is 23 or 25 hours away. Add a day in local time, then convert.
- The server's zone
- Code that relies on DateTime.Now, GETDATE() or the default zone behaves differently on a server set to UTC, in a container, or in a data centre in another country. Pass the zone explicitly.
- Windows and IANA names
- SQL Server's AT TIME ZONE wants "GMT Standard Time"; browsers and most libraries want "Europe/London". .NET 6 and later accept both and convert between them.
Where the answers come from
Everything is calculated from the time zone database built into your browser (the IANA database, which the browser updates with itself), using the Intl API and nothing else. The clock changes for a year are found by scanning it hour by hour and narrowing each change down to the minute. A local time is resolved by trying each offset in force around that date and keeping the ones that land back on the same wall-clock time: one means it is unique, two means the hour was repeated, none means it was skipped.
The Windows time zone name comes from the Unicode CLDR mapping, which is what .NET uses to convert between the two naming schemes. Rules change: governments move or abolish daylight saving at short notice, so a date years ahead is a prediction from today's rules.
Booking, scheduling or billing software that trips over the clocks?
We have fixed this class of bug in systems used across Europe. Tell us what goes wrong and when.