> Any approach will require updating CLDR If you're talking about abbreviations, CLDR does not look at them, just at tm_isdst. We would publish the same ignore-tm_isdst treatment as we have done for Vancouver and Edmonton (and would similarly ask for a grace period for tm_isdst, thanks for doing that for Edmonton as well).
Personally I think TZDB should move away from abbreviations and just use %z. Few jurisdictions actually assign names/abbreviations to their time zones (mainly multi-timezone countries, but not even all of those), sometimes they're not globally unique (Australia vs Canada/US Eastern Time, which seems to have caused problems in the past), and it seems at odds with TZDB's more recent policy to deduplicate zones across borders with the only requirement being that clocks agree (which manifests itself in the issues mentioned earlier about Phoenix/Puerto Rico). > Perhaps eventually common practice would become clear and we could start using alphabetic abbreviations again. Until things settle down, though, numeric abbreviations would likely cause fewer problems than alphabetic ones. Common practice has been clear for ~50 years, yet this is becoming a problem now. TZDB, common usage, and the legislature all have different stability requirements, and using either legal names or common practice will lead to problems down the road. The only thing that is 100% certain are the offsets. Both the names and the tm_isdst flag are moving targets and up to interpretation. CLDR already spends a lot of effort on figuring out these common-use aspects, but makes it clear that these are moving targets and for human display, not for protocol usage. This does not seem to be so clear for the TZDB data. On Mon, 20 Jul 2026 at 14:16, Brooks Harris via tz <[email protected]> wrote: > On 2026-07-19 04:41 AM, James Bellaire via tz wrote: > > On 7/19/2026 3:32 AM, Paul Eggert via tz wrote: > > On 2026-07-18 13:03, Guy Harris via tz wrote: > > And encourage developers to 1) not rely on "EST" in a string meaning > UTC-05 etc., 2) stop using "EST" etc. in time stamp strings and switch to > UTC±N, > > > Good advice, and it suggests that if the US changes go through as > proposed, TZDB should follow Robert's suggestion[1] and switch North > American time zone abbreviations from the (A|E|C|M|P|AK)(D|S)T abbreviation > family to numeric abbreviations like "-04". This would help avoid collision > with longstanding practice that includes both standards like Internet RFC > 5322 and software packages galore. And we'd be following our own advice to > not generate abbreviations like "EST". > > Perhaps eventually common practice would become clear and we could start > using alphabetic abbreviations again. Until things settle down, though, > numeric abbreviations would likely cause fewer problems than alphabetic > ones. > > > The suggestion is to use numeric abbreviations such as "-04"? One might as > well set it at %z. > > I believe the FORMAT field in the current form has value. My option is > that the FORMAT field should be maintained as a "best effort" name for how > people in that zone refer to their time. > > > If one wants to get wild we could use USET, USCT, USMT, USPT, USAK, USHI, > USAZ, USPR, USAT (for America/Thule's Atlantic Time). Canada can have > CAEST/CAEDT, CACST/CACDT, CAMST/CAMDT, CAPT ... wherever those zones end > up. > > What would break is using America/Puerto_Rico and America/Phoenix in > Canada and expecting the FORMAT to be correct. So we're back to "AST" and > figure out something for America/Thule if the US goes permanent DST. > > > I manually made the following experimental modifications to > America/New_York in the northamerica source file: > > # Rule NAME FROM TO - IN ON AT SAVE LETTER/S > .... > Rule US 2007 2027 - Mar Sun>=8 2:00 1:00 D > Rule US 2007 2027 - Nov Sun>=1 2:00 0 S > > # Zone NAME STDOFF RULES FORMAT [UNTIL] > #STDOFF -4:56:01.6 > Zone America/New_York -4:56:02 - LMT 1883 Nov 18 17:00u > -5:00 US E%sT 1920 > -5:00 NYC E%sT 1942 > -5:00 US E%sT 1946 > -5:00 NYC E%sT 1967 > -5:00 US E%sT 2027 Mar 14 2:00 > -4:00 - -04 > > I then Generated a set of tzIF files using my adapted version of zic. > And then ran my adapted version of zdump, which output the two last > transitions as: > > [217] > 1793512799 2026-11-01 01:59:59 isdst 1 gmtoff -14400 stdoff -14400 EDT > 1793512800 2026-11-01 01:00:00 isdst 0 gmtoff -18000 stdoff -14400 EST > 1793512801 2026-11-01 01:00:01 isdst 0 gmtoff -18000 stdoff -14400 EST > [218] > 1805007599 2027-03-14 01:59:59 isdst 0 gmtoff -18000 stdoff -14400 EST > 1805007600 2027-03-14 03:00:00 isdst 0 gmtoff -14400 stdoff -14400 -04 > 1805007601 2027-03-14 03:00:01 isdst 0 gmtoff -14400 stdoff -14400 -04 > > So, those source changes work correctly without any modification to my zic > or zdump code. > > My opinion this morning (which could change by midday) is that this is the > best way to do it. > > I appreciate the idea of maintaining FORMAT. Paul has suggested restoring > EST sometime later. But I think we should dispense with that. > > The main point of FORMAT, as I understand it, was to keep POSIX > abbreviations happy. But that convention originated decades ago when POSIX > time (UNIX time), and TzDb (Olson) was primarily directed to support USA > time zones. This has led to TzDb inventing all sorts of versions of FORMAT > to follow this tradition. This has worked OK for years. But POSIX seems > happy enough with FORMAT such as "-04". I think that approach makes more > sense going forward. I expect to hear other opinions. Of course we can't > change those that exist. > > I've only tested America/New_York so I suppose there could be > complications in other time zones. Any approach will require updating CLDR > and downstream distributions. And it's likely to set off changes in Mexico, > Canada, EU, etc which will then need to be accommodated. > > I hope the Senate does not pass the Sunshine Protection Act. > >
