| ?? | TZ identifier | TZ named offset | ↓ UTC offset | Diff | Local date | Local time |
|---|
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.
Yes, of course the 24-hours clock is used (and not the 12-hours clock together with AM/PM) and there is no way of changing that. The formats for date and time are according to ISO 8601. Since the UTC time zone (Zulu-time) is so vital, there is no way to hide it. At the moment (October 2019), time zones spanning from UTC-12:00 to UTC+14:00 are used around the world in practice, but I have also included support for some theoretical time zones in the span from UTC-48:00 to UTC+48:00, since they are great when analyzing. Enhance your knowledge and dig deep into time zones.
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.
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:
You can link directly to the analyzing table, by appending the fragment URL #analyzingTable, for example http://anders.nemonisimors.com/projects/timeZones/#analyzingTable.
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.
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 %2B, e.g. tz=%2B05:00).
http://anders.nemonisimors.com/projects/timeZones/?dateTime=2020-01-01T00:00:00&tzIdentifier=UTC
http://anders.nemonisimors.com/projects/timeZones/?tzIdentifier=UTC&tz=UTC
http://anders.nemonisimors.com/projects/timeZones/?tzIdentifier=Asia/Kathmandu
http://anders.nemonisimors.com/projects/timeZones/?dateTime=2019-10-27T00:59:59&tzIdentifier=UTC#analyzingTable
http://anders.nemonisimors.com/projects/timeZones/?tzIdentifier=America/New_York&tz=Europe/Stockholm&tz=America/Los_Angeles&tz=America/New_York&tz=Australia/Perth&tz=Africa/Johannesburg
http://anders.nemonisimors.com/projects/timeZones/?tzIdentifier=Pacific/Auckland&tzComparing=Pacific/Honolulu&tz=UTC#analyzingTable
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
.
NNM Time zones is built with plain JavaScript and styling is made with help from Bootstrap (v4.3.1). The JavaScript datetime logic is accompanied by the Luxon (v1.21.1) date and time handling library (since you never ever want to be on your own when dealing with time zones in programming). Luxon has great documentation about time zones and please, pay special attention to the section about DST weirdness, containing interesting information like:
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 <major>.<minor>.
1.3 was released 2019-11-09.
1.2 was released 2019-11-03.
1.1 was released 2019-10-26.
1.0 was released 2019-10-16.