|??||TZ identifier||TZ named offset||↓ UTC offset||Diff||Local date||Local time||Zoned datetime|
NNM Time zones - an educational analyzing tool for playing around with time zones. You can either view real local times around the globe or simulate different time zones and different local times.
If there is a simulated current local datetime value (for example
2019-10-27 01:00:00 or
2019-03-31 03:00:00), the real-time ticking is disabled and you have to decrease/increase the clock manually. The time zone used for this local datetime value is the value from current local time zone. You can decrease/increase the year, month, day, hour, minute or second values and there are accesskey attributes defined on these buttons for convenience.
A little warning: You may enter harmless "infinite" loops. For example when increasing the minutes and your new value matches the timestamp when DST (daylight saving time) ends, you may be thrown back an hour, and when you keep increasing minutes you will eventually hit that strange point again, and be thrown back an hour.
Friendly reminder: As always, you have to be careful when analyzing future datetime values, since they may or may not be what you expect when the time comes! Time zone rules are changing all the time! The only times you can trust are those in the past.
Note: Since most time zone abbreviations (like CET, EST, PST) are completely useless, they are not found in any of the time zone lists. Only time zone identifiers (area/location) and offsets are supported (and of course the almighty UTC).
Time zones currently using daylight saving time are indicated with a ☆ in the UTC offset column.
Some rows in the table are marked with different background colors for easier recognition:
|Zulu time (the one and only time to really care about)|
|Current simulated or real browser time|
|Primary time zone to compare|
You can link directly to the analyzing table, by appending the fragment URL
#analyzingTable, for example
The following access keys are used for your convenience:
By defining parameters in your URL you can easily link to specific views of the analyzing table.
The following parameters can be used:
dateTime=2019-11-07T23:45:00. If defined, simulated mode is activated. If missing, real-time mode is used.
tzIdentifier=America/New_York. If missing, your browser's actual time zone will be used.
tzComparing=Europe/Paris. If missing, the default comparing time zone (currently
America/Los_Angeles) is used.
tz=America/New_York&tz=America/Los_Angeles&tz=Australia/Perth. If missing, the default time zones are shown. This parameter can be used to add your own identifiers.
None of the parameters are mandatory. All parameters can be used independently.
If you want to use positive UTC offsets, you may skip the plus as prefix. For example, use
tz=05:00 instead of
tz=+05:00 (since otherwise you must properly URL encode the
+ with a
Note: I would argue that the UTC±99:55 time zones are no crazier than any of the other time zones that we are using.
Even though I have implemented this tool, I truly advocate that time zones should be destroyed. I am even more convinced than before, now that I have worked with a project that literally has to deal with time zones complexity and some of all the peculiar quirks.
Although it has been a fun project, it is way too many moving parts involved, so the risk of errors when handling different time zones is high. The daylight saving time complexities, erroneous implementations and updates of the actual rules for some of the time zone identifiers and datetime values in the future are probably the worst parts. The only thing you can be sure of is that errors exist, or as Edsger Dijkstra put it:
Testing can show the presence of errors, but not their absence.
Because our ancestors were morons, they opted for a system wherein many governments shift around the local time twice a year for no good reason. And it's not like they do it in a neat, coordinated fashion. No, they do it whimsically, varying the shifts' timing from country to country (or region to region!) and from year to year. And of course, they do it the opposite way south of the Equator. This is all a tremendous waste of everyone's energy and, er, time, but it is how the world works and a date and a time library has to deal with it.
NNM Time zones is implemented by Anders Gustafson. If you have any questions, ideas, errata, etc, please send me an email: andersatnemonisimorsdotcom
The version numbering uses the pattern
1.6.4was released 2023-06-03.
1.6.3was released 2022-03-28.
1.6.2was released 2022-03-07.
1.6.1was released 2021-12-25.
1.6.0was released 2021-09-05.
1.5.3was released 2021-07-14.
1.5.2was released 2021-05-15.
1.5.1was released 2021-01-06.
1.5.0was released 2020-12-30.
datetime-localtype for the Simulated current local datetime input field, for a better user experience.
1.4.0was released 2020-12-28.
1.3.1was released 2020-10-30.
1.3.0was released 2019-11-09.
1.2.0was released 2019-11-03.
1.1.0was released 2019-10-26.
1.0.0was released 2019-10-16.