Hi there,
Respectfully, this is a technical group whose interests are making sure time is correctly calculated and thereby accurately reflected within technical platforms moving forward. Utilizing other knowledge sources or media organizations to voice concerns about vigilance in updating systems may be more a more effective way to communicate disruptive changes. Best, Jake On Saturday, 3. October 2026 23:43:50 (+02:00), peter--- via tz wrote: Hi I am a business consultant based in Victoria, BC, Canada. I became aware of an impending problem when our provincial government decided to ‘pull the switch’ and ditch Standard Time early this year. I was curious how it all worked and what had to change behind the scenes. My knowledge of the processes involving CLDR and tzData at the time was zero – like most people not ‘in the know’. I have learned a lot following this discussion over the last six months or so and the more I learn the more concerned I get about how the real world is going to cope. Microsoft has only recently pushed Windows Update 26H2, the first that contains the new BC time zone – and so far only to some streams. It will be late October before most users have the update. Nothing about it tells users they have anything else to do and IT managers seem oblivious to the problem in the main. Users have to manually change their time zone. Having 26H2 is not enough – you are still on Pacific Time US & Canada, which maps to America/lLosAngeles and will fall back in November. Microsoft also made available a paper pointing out that Outlook and Teams (and, by implication, lots of other similar non-MS software) sets events in UTC at the time the event is set, using the then-current local time zone. So, any meetings set up for after the next clock change are already wrong – and users do not even know that. This is orders of magnitude worse than Y2K – which was reasonably dealt with by IT staff and basically did not really involve end users at all. This is different. It most certainly DOES involve end users – and they are basically not aware of an impending issue. This already involves any future-dated time events that have been set while on the old time zone. That this involves most every timetable is quite scary. Yes airlines, for example, plan their slots based on UTC, but those map back to where they were expected to be when the timetable was set up. I don’t know what the solution is, but I know that the experts in IANA and those dealing with CLDR, as well as the suppliers like Microsoft etc, will all be held at fault if (when) the s*** hits the fan. Personally, I think a formal press release should be issued, ideally signed by all the above, drawing PUBLIC attention to the impending crisis. The fix will need to come from end user IT managers and database/application teams. So far, everyone seems to be sleepwalking into this without a care. Peter Aggus From: Mark Davis Ⓤ via tz <[email protected]> Sent: October 3, 2026 2:00 PM To: Tim Parenti <[email protected]> Cc: [email protected] Subject: [tz] Re: Suggestion: ATTENTION lawmakers and timekeeping authorities We've discussed in Unicode about putting up a page with a similar warning. I would encourage an IANA web page on the topic. While the TZDB is unknown to many people, a page would provide a place for others to link to. Note that for Unicode (CLDR) there are the additional constraints imposed by names. We have one 'generic' name for time zones that don't have daylight savings, and three for ones that do; and in ~100 different languages, plus acronyms (where they are widely recognized). And it is harder for implementations to update names x languages than it is for the TZDB data we're based on. It would be terminally confusing for speakers of English, for example, to have "13 October 2026 14:30 Pacific Time" mean two different UTC times in different countries. Mark On Sat, Oct 3, 2026 at 1:25 PM Tim Parenti via tz <[email protected] <mailto:[email protected]> > wrote: On Sat, 3 Oct 2026 at 15:58, Brooks Harris via tz <[email protected] <mailto:[email protected]> > wrote: Why not put a notice on the main IANA TzDb page in BIG RED LETTERS Although we do have some basic guidance in tz-link.html, it is admittedly a bit hidden: https://data.iana.org/time-zones/data/tz-link.html#coordinating (So hidden that I keep accidentally looking for it in theory.html instead.) We could probably stand to beef that up with some harder data and/or make it more visible in the distribution. For that purpose, the timeline that Christian Cruz posted about the America/Coyhaique zone's (not-so-recent) creation may be illustrative: https://lists.iana.org/hyperkitty/list/[email protected]/message/5I4VYFK5QQHKELZIEDZIT3OGTQ57WWEL/ Chronicling aspects of the fuller data lifecycle on a site like my https://tzdata-meta.timtimeonline.com/ could also be helpful. That said, putting it in red letters on the IANA page is not likely to accomplish much. As others have pointed out, governments and the general public aren't always aware of our project to begin with. -- Tim Parenti
