> there are >300 timezone names while only ~40 timezone offsets update/number crunching: at the time of writing - https://arkenfox.github.io/TZP/tests/timezones.html - `444` "supported" timezone names - `596` timezone names tested if you uncheck `supported` - the only invalid one now is `Factory` - does not alter the final group count - `152` extra timezone names IIUIC act as aliases for a supported one - `58-59` seems to be the number of timezone offsets _over_ a year (for recant years, not old-timey stuff) - concurrent varies at any given point but is around 40 IIRC - e.g. 2023 = 58, 2024 = 59, 2025 = 58, 2026+ = 58 - therefore the minimum timezone names we could be those combined over our _supported_ years - e.g. 2023-2026+ = 62 testing with `444` supported timezone names - without affecting any datetime: i.e any offsets are correct throughout history/calendars - we can reduce this to `338` - e.g. `America/Lower_Princes, America/Marigot, America/Montserrat,...` are identical - e.g. `Asia/Dubai, Asia/Muscat, Indian/Mahe, Indian/Reunion` are identical - with only ensuring 1990+ datetime is always correct we can reduce this to `214` - with only ensuring 2000+ datetime is always correct we can reduce this to `171` - with only ensuring 2010+ datetime is always correct we can reduce this to `132` - with only ensuring 2020+ datetime is always correct we can reduce this to `73` - enter `2020, 2021, 2022, 2023, 2024, 2025, 2026, 2027` into the field and run `combined` - of which `45` are unique with a single member: which is a little misleading, because some of those with 2 or 3 are only grouped with `Etc/` - e.g. `Pacific/Fiji` is a group, so unique - e.g. `Etc/GMT-14, Pacific/Kiritimati` is a group of 2, but in reality is unique - there isn't much we can do about the long thin tail - but there are large groups: look at the group summary: e.g. `33, 32, 28, 23, 17, 16, 16, 16, 16, 15, 15, 14, 13, 11, 11, 10, 10, 10, 10 ...` - e.g. these 33 timezone names - > ``` > Africa/Ceuta, Arctic/Longyearbyen, Europe/Amsterdam, Europe/Andorra, Europe/Belgrade, Europe/Berlin, Europe/Bratislava, Europe/Brussels, Europe/Budapest, Europe/Busingen, Europe/Copenhagen, Europe/Gibraltar, Europe/Ljubljana, Europe/Luxembourg, Europe/Madrid, Europe/Malta, Europe/Monaco, Europe/Oslo, Europe/Paris, Europe/Podgorica, Europe/Prague, Europe/Rome, Europe/San_Marino, Europe/Sarajevo, Europe/Skopje, Europe/Stockholm, Europe/Tirane, Europe/Vaduz, Europe/Vatican, Europe/Vienna, Europe/Warsaw, Europe/Zagreb, Europe/Zurich > ``` - could use and report as `Europe/Paris` - if we supported accuracy only for the last year (2024) + current year + future we can reduce this to `60` Note: all groupings would need to be checked/updated with tzdata changes. As we ignore older datetime accuracy, we reduce minimum viable timezone names (see offsets over supported years). The question becomes at what point do we care about accuracy in older calendar entries. Reduction from 444 (or 596?) _possible_ (IDK how many are used in reality) timezone names to ~60-70 (with a long thin tail) seems feasible, with minimal usability issues - e.g. you order a local pizza it has your correct local time, you look up calendar entries, send emails, add calendar entries in the future - all correct time.
Bug 1719738 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
> there are >300 timezone names while only ~40 timezone offsets update/number crunching: at the time of writing - https://arkenfox.github.io/TZP/tests/timezones.html - `444` "supported" timezone names - `596` timezone names tested if you uncheck `supported` - the only invalid one now is `Factory` - does not alter the final group count - `152` extra timezone names IIUIC act as aliases for a supported one - `58-59` seems to be the number of timezone offsets _over_ a year (for recent years, not old-timey stuff) - concurrent varies at any given point but is around 40 IIRC - e.g. 2023 = 58, 2024 = 59, 2025 = 58, 2026+ = 58 - therefore the minimum timezone names we could use would be those combined over our _supported_ years - e.g. 2023-2026+ = 62 testing with `444` supported timezone names - without affecting any datetime: i.e any offsets are correct throughout history/calendars - we can reduce this to `338` - e.g. `America/Lower_Princes, America/Marigot, America/Montserrat,...` are identical - e.g. `Asia/Dubai, Asia/Muscat, Indian/Mahe, Indian/Reunion` are identical - with only ensuring 1990+ datetime is always correct we can reduce this to `214` - with only ensuring 2000+ datetime is always correct we can reduce this to `171` - with only ensuring 2010+ datetime is always correct we can reduce this to `132` - with only ensuring 2020+ datetime is always correct we can reduce this to `73` - enter `2020, 2021, 2022, 2023, 2024, 2025, 2026, 2027` into the field and run `combined` - of which `45` are unique with a single member: which is a little misleading, because some of those with 2 or 3 are only grouped with `Etc/` - e.g. `Pacific/Fiji` is a group, so unique - e.g. `Etc/GMT-14, Pacific/Kiritimati` is a group of 2, but in reality is unique - there isn't much we can do about the long thin tail - but there are large groups: look at the group summary: e.g. `33, 32, 28, 23, 17, 16, 16, 16, 16, 15, 15, 14, 13, 11, 11, 10, 10, 10, 10 ...` - e.g. these 33 timezone names - > ``` > Africa/Ceuta, Arctic/Longyearbyen, Europe/Amsterdam, Europe/Andorra, Europe/Belgrade, Europe/Berlin, Europe/Bratislava, Europe/Brussels, Europe/Budapest, Europe/Busingen, Europe/Copenhagen, Europe/Gibraltar, Europe/Ljubljana, Europe/Luxembourg, Europe/Madrid, Europe/Malta, Europe/Monaco, Europe/Oslo, Europe/Paris, Europe/Podgorica, Europe/Prague, Europe/Rome, Europe/San_Marino, Europe/Sarajevo, Europe/Skopje, Europe/Stockholm, Europe/Tirane, Europe/Vaduz, Europe/Vatican, Europe/Vienna, Europe/Warsaw, Europe/Zagreb, Europe/Zurich > ``` - could use and report as `Europe/Paris` - if we supported accuracy only for the last year (2024) + current year + future we can reduce this to `60` Note: all groupings would need to be checked/updated with tzdata changes. As we ignore older datetime accuracy, we reduce minimum viable timezone names (see offsets over supported years). The question becomes at what point do we care about accuracy in older calendar entries. Reduction from 444 (or 596?) _possible_ (IDK how many are used in reality) timezone names to ~60-70 (with a long thin tail) seems feasible, with minimal usability issues - e.g. you order a local pizza it has your correct local time, you look up calendar entries, send emails, add calendar entries in the future - all correct time.