On 2026-03-06 15:04, Robert Bastian wrote:
TZDB updates are basically immediate in most major systems
They are not immediate for many of the systems I use. It can take many months, particularly with devices that are not networked or that are maintained only fitfully by their suppliers. The TZDB project asks for at least a year's notice for this sort of thing because updates can take quite a while to percolate downstream.
We don't need to release a new TZDB today. But we should not target months from now. We should get this done soon.
I get that TZDB puts a lot of value on following some law to the letter, but the BC government has explicitly announced this summer as a transionary period, so I don't understand why you have to release this change 5 days later if a major library is telling you that this will break them.
I don't see a major breakage here. If I understand things correctly, America/Vancouver people combining older CLDR with newer TZDB would see "Pacific Standard Time" instead of the legally-specified "Pacific Time". Although infelicitous to experts, that string isn't "broken": it's close enough to the real thing for most users, and only time pedants and maybe politicians will care.
Though I'm still a bit confused by this, as you mentioned that CLDR is planning to patch the copy of TZDB that it contains, in which case such a combination won't occur and the issue is moot for now (though of course we'd like to remove the need for any such patch later on, as CLDR's schedule permits).
Or are you referring to Mark's point that "Pacific Time" in many user interfaces means "Pacific Standard Time or Pacific Daylight Time, depending on the time of year", and that it's confusing if "Pacific Time" also means time in British Columbia? If so, I can see that this is a pain but there are surely other ambiguous phrases in CLDR and user interfaces don't collapse because of them. (Of course this is an issue for CLDR to decide; TZDB doesn't need to worry about those long strings.)
