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

Reply via email to