> Will this month's new CLDR stick with the name "Mountain Daylight Time" > for Alberta's timekeeping, and will it allow "Mountain Time" as a > generic name for this new timekeeping even though Alberta doesn't have > alternatives for summer and winter?
This is a problem that already exists with America/Phoenix. I think ICU uses "Mountain Standard Time" for Arizona's generic time, which makes sense but is not what CLDR specifies. It would make sense to do the same for permanent-DST zones, and to spec that. > And what will CLDR do for "Mountain > Standard Time" in Alberta - will that string be forbidden in Alberta, or > never generated? Or am I misreading the tables again? I think this question is about parsing, which I don't know the answer to. Parsing localized time zone names is generally not a good idea. On Wed, 7 Oct 2026 at 04:52, Steven R. Loomis <[email protected]> wrote: > See also > https://www.unicode.org/reports/tr35/dev/tr35-dates.html#Using_Time_Zone_Names > > As to “Alberta time”, outside of where local abbreviations are available, > the generic location name may be used. Examples at > https://st.unicode.org/cldr-apps/v#r_zones/da// (These are examples, not > production data). “ Edmonton-tid” which I think is “Edmonton time” > > -s > > Enviado desde mi iPad > > El oct 6, 2026, a la(s) 6:44 p.m., Paul Eggert via tz <[email protected]> > escribió: > > On 2026-10-06 12:19, Robert Bastian wrote: > > The changes linked above effectively ignore TZDB's decision to model these > > changes as new standard times. > > > Thanks for explaining. Some more comments plus a couple of questions. > > As I understand it, after November 1 neither CLDR nor TZDB will use the > English-language abbreviations suggested by the respective regional > governments. For the new timekeeping we have: > > 0 1 2 3 > -07 MST PDT PCT America/Vancouver > -06 CST MDT ABT America/Edmonton > -06 CST MDT ??? America/Inuvik > -05 EST CDT MBT America/Winnipeg > > where column 0 is the UT offset, column 1 is the abbreviation that TZDB > will use, column 2 is what CLDR will use, and column 3 is what the > respective governments suggest (NWT does not suggest so I listed "???".) > > This disagreement is unfortunate but I don't see a simple solution other > than maybe just going with column 0 in TZDB for now. Although columns 1 and > 2 are both compatible with a lot of existing software and standards (e.g., > Internet RFC 5322), neither column is likely to match what people will say; > and although column 3 attempts to avoid that confusion it is at the expense > of compatibility and it regionalizes abbreviations in a way that will > likely have significant problems. > > I don't see anything in bleeding-edge CLDR mentioning "ABT" or "Alberta > Time", or similarly for the other government-suggested abbreviations or > names, so it looks like CLDR is also holding off on column 3 for now. Will > this month's new CLDR stick with the name "Mountain Daylight Time" for > Alberta's timekeeping, and will it allow "Mountain Time" as a generic name > for this new timekeeping even though Alberta doesn't have alternatives for > summer and winter? And what will CLDR do for "Mountain Standard Time" in > Alberta - will that string be forbidden in Alberta, or never generated? Or > am I misreading the tables again? > > Also, it seems the phrase "Pacific Time" is uniquely problematic here, as > it exactly matches the legal name for -07 in BC whereas CLDR uses it as a > generic name for both -08 and -07. We won't have this problem with > "Manitoba Time" and "Alberta Time", though we will have other problems. > >
