Microsoft's Canada Timezone Troubles Leave Admins Fixing Calendars, Pretending They're In Bogota (theregister.com) 67
Microsoft is scrambling to fix time-zone problems across Outlook, Power Automate, Fabric, SharePoint and other products after parts of Canada stopped observing seasonal clock changes on November 1. "The company has confirmed problems across a chunk of its software estate, leaving some customers facing incorrect times, broken schedules and a collection of workarounds while Redmond catches up," reports The Register. From the report: Outlook users have been left with the most homework. Switching to the new Canadian time zones won't automatically update existing calendar entries, meaning that meetings scheduled after November 1 are potentially an hour out of whack. Microsoft advises users to change their Outlook calendar time zone, then update upcoming events and meetings to use it. For meetings involving other people, only the organizer can make the change.
Recurring meetings come with an additional treat: changing the time zone resets any previously moved occurrences, which then have to be recreated. Anyone with a calendar full of recurring meetings may wish to put the kettle on first. Microsoft is working on an Exchange Online PowerShell cmdlet to remediate non-recurring meetings, but according to its guidance, that's not due until later this week. A fix for recurring meetings remains "in development," with an ETA yet to be confirmed.
Things get stranger with Power Automate and Fabric, where Microsoft's temporary fix involves pretending you're somewhere else entirely. Depending on the product and province, that could mean Saskatchewan, Arizona or, for Manitobans, Bogota. Because apparently time zones weren't confusing enough already. SharePoint On-Prem customers, meanwhile, have to wait until November 10 for the correct time zones to arrive, while Power Pages users could see server-formatted dates appear an hour out until a service fix lands. Microsoft's current milestone for that is December 12.
Recurring meetings come with an additional treat: changing the time zone resets any previously moved occurrences, which then have to be recreated. Anyone with a calendar full of recurring meetings may wish to put the kettle on first. Microsoft is working on an Exchange Online PowerShell cmdlet to remediate non-recurring meetings, but according to its guidance, that's not due until later this week. A fix for recurring meetings remains "in development," with an ETA yet to be confirmed.
Things get stranger with Power Automate and Fabric, where Microsoft's temporary fix involves pretending you're somewhere else entirely. Depending on the product and province, that could mean Saskatchewan, Arizona or, for Manitobans, Bogota. Because apparently time zones weren't confusing enough already. SharePoint On-Prem customers, meanwhile, have to wait until November 10 for the correct time zones to arrive, while Power Pages users could see server-formatted dates appear an hour out until a service fix lands. Microsoft's current milestone for that is December 12.
IST (Score:2)
Yeah that's why I just schedule all my meetings in India Standard Time.
Re: (Score:2)
Re: (Score:3)
I tried to use Swatch Internet Time but Outlook still doesn't recognize scheduling meetings with @beats
Alberta, figures... (Score:2)
Good thing they don't do anything complicated up there like scheduling trains. Or airplanes.
Re: (Score:2)
Indeed, you are not obligated to use the Microsoft time servers in Windows. You really should use more local ones, as those have a much better idea of when DST events happen.
The maintainers of the Microsoft time servers have been spectacularly bad in my case, here in the South-Americas. Always timing issues when DST was applied. But after configuring 1.south-america.pool.ntp.org all transitions went practically always perfectly. So no, no more Microsoft time severs for me. However, time-zones do remain a pr
Those who cannot remember the past... (Score:2)
Re:Those who cannot remember the past... (Score:5, Interesting)
The 'prior art' is not y2k but rather the DST change in 2006 (to our current weekends in North America).
That was when they restructured most of their timezone information into easily updated files that made the operating system generally adapt pretty quickly, along with client-side software for anything *newly* generated in scheduling software.
However, the issues here are what to do about already-existing scheduled events - how do they adapt depends on what your internal model is for storing "where" they are (which timezone they're meant to follow). If you didn't separate out America/Vancouver in your system because it was always the same as America/Los_Angeles...it is an almost unfixable problem because you have no way to isolate what is and isn't in "Canada".
So this is why I've been saying, for months now since it was announced, that it was going to be a mess because there wasn't enough time to develop and test the solutions in the middle of all of the other work that app teams are doing (often with reduced resources due to the layoffs of the last 3 years) before everything went live. You really want this stuff tested AT LEAST 6 months before the first change, preferably a full year.
I can't imagine the scheduling disasters for anybody actually using Egypt time over the last 15 years, when they ditched DST, *partially* brought it back (the day would change based on Ramadan) and then in March of '23 announced that in April of '23 they would go back to switching. Pretty sure anybody of any import just set their clocks collectively to something from Europe for the stability.
Re: (Score:2)
Shouldn't we expect (in the sense of demanding, not in the sense of actually expecting) Microsoft to be ready for changes like this? This isn't the first time it's come up.
Re: (Score:2)
Oh man, I remember that. Over several months, Microsoft issued something like 60 consecutive patches ahead of the change... and everyone's Outlook calendar meeting entries were still off by an hour.
Re: (Score:2)
You would think professional software engineers for one of the largest tech companies in the world would have enough foresight to get this done right and on time. I suppose that would require them to care about their users. Oh well, enjoy your Microsoft experience folks.
Re: (Score:3)
It's not just Microsoft. Google Calendar is similarly affected (my appointments are now off by an hour because Google originally scheduled them in MST). Just about any calendaring system, even open source ones, that lets you schedule events in the future or recurring events that cross former DST/standard time shift boundaries are affected.
Being is Bogota timezone is not the same (Score:2)
Can't we define the timezone as a UTC offset? (Score:2)
Re: (Score:2)
Funny enough my Windows 10 laptop had the correct time, because it was set to Vancouver. However Windows 11 machines were not, because they were set to Pacific/Americas. The option to select British Columbia's time wasn't available unless I turned "automatically change for DST" off.
Re:Can't we define the timezone as a UTC offset? (Score:5, Informative)
Can't we define the timezone as a UTC offset? I thought WIndows, macOS and Linux all allowed that?
On Linux in this case you can use the Etc/GMT+5 timezone (note the POSIX inversion is not a typo), which is a permanent UTC-5 with no DST changes.
Re: (Score:1)
Well, we (the little people) can't. We're stuck with the global timezones, and if your town falls in Bogota's swath or Chicago's swath or Leningrad's swath... that's all you need to figure all that out.
I doubt they're going to rewrite the whole system because you're in Vancouver (which falls in the same timezone as something else)... as long as it results in the same time, it doesn't really matter.
Re: (Score:2)
Yes, all timezones are defined as UTC offsets. The problems occur when governments change things (like when DST starts or ends, or whether it even happens). And even that's not a problem. But you need to get the updated timezone files to computers. Which should be trivial for Microsoft, since the laws were passed a few months ago.
There have been problems in the past when countries have changed rules a week before the change matters. But... this should have been enough time.
Re: (Score:2)
MS Windows keeps the TZ definitions in the registry, not files. Either way though, there's no reason MS couldn't have pushed the update out correctly. The problem is, changing the way time zones work can cause real problems with scheduled jobs regardless of TZ (as demonstrated with PA and Fabric especially,) so it needs to go through proper QA before rollout. Clearly MS didn't do the prerequisites.
Re: (Score:3, Interesting)
I don't really agree. Timezones, DST, and TZ definitions are very well understood. Every year several (mostly small) countries make last-minute TZ changes and they get pushed out and handled; this is not new and untested tech. Sure we need some level of QA; we always need more testing! but changing a TZ file has very few side effects. All internal time info is already stored at UTC, so the TZ changes how it is displayed but not how it is consumed or calculated. MS did not push out critical changes for
How did no one test this? (Score:3)
Re:How did no one test this? (Score:4, Insightful)
From the summary it sounds like they did adjust the timezones but they didn't anticipate that anyone would actually change timezones. That doesn't particularly surprise me since Windows doesn't even have a setting to keep the system clock in UTC.
Re: (Score:2)
womp womp [the.hosting]
Re: (Score:2)
Yes it does.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=dword:00000001
Re: (Score:3, Funny)
Adding to the increasing list of things Microsoft can't manage, telling time . . . maybe they should visit an elementary school, I'm sure a Jr K teacher could help them.
I don't think anybody can help a company whose approach to installing a light-bulb is to hold the bulb in place and rotate the building. Oh, and when they fail at that they simply declare darkness as the new standard.
Re: (Score:2)
Re: (Score:3)
The changes to Canadian timezones didn't happen on short notice, they were established months ago. Microsoft had more than enough time to adjust all the timezones, meaning this screw up is intentional. Adding to the increasing list of things Microsoft can't manage, telling time . . . maybe they should visit an elementary school, I'm sure a Jr K teacher could help them.
My province of MB was definitely short notice, becoming official in mid-September. That change is included in IANA 2026e tzdata. Changes for Inuvik were in IANA 2006d, and British Columbia had the longest notice, with changes are in IANA 2026c.
Re: (Score:2)
Re: (Score:3)
Unless the change occurred within a couple of day, there was no excuse.
You've never worked in an enterprise, have you?
Re: (Score:2)
When I worked at Research in Motion now Black Berry, to file a bug report against an app I tested was insane. I had to send the bug report to the Project Management department, who would almost always change it, then work with the developer, who almost always never knew what they were talking about. Then, I would get the
Re: (Score:3)
WAT?
It takes more than couple days to test and push software patches. You do want things tested right, you'd hate get a TZ file where someone fat fingered something and systems set to a given zone all default to GMT or something right because they can't parse the row needed?
Also it isn't just computers timezone change impact. Contracts may involve hourly payments etc, and people might need to negotiate changes; not many people maybe but not nobody.
Honestly I don't see any universe where responsible govern
Re: (Score:2)
What I said, to be fair, was you couldn't expect them to make this change, with only a couple of days of notice. Which I think is a fair statement, they
Re: (Score:3)
And what about events that were scheduled in the calendar well in advance (months or years)? These are the problems. In fact I just noticed all my google calendar evens from November through March are 1 hour off now. The only way to fix them is to edit each one, set the originating time zone to my now current UTC offset, and then it will correct the backend UTC entries to their proper hour. (yes the backend is in UTC).
Did they forget to push out the tzdata rpm? (Score:3, Insightful)
I guess I'm spoiled in Linux, Fedora and CentOS in particular. the package tzdata gets updated several times a year, most recently a month ago. Adjustments are not even noticed.
As a Canuck ..... (Score:5, Funny)
I did love the recent headline in The Beaverton (our version of The Onion).
No one in Canada knows what time it is anywhere else in Canada
Re: (Score:2)
I did love the recent headline in The Beaverton (our version of The Onion).
No one in Canada knows what time it is anywhere else in Canada
I'll admit I don't, but it will become more clear when the dust settles. The new PQ government in Quebec may be changing soon from the sound of it, which might cause Ontario to have another look...
Re: (Score:2)
I mean, come on, permanent DST in CANADA?!?!?! When does the sun rise, sometime after noon? Did your legislators forget how far y'all are from the equator?
Well, don't worry, it'll probably go like it did in the US in the 70's and be undone due to a massive backlash.
The conspiracy theorist in me (Score:2)
Part of me wonders if this is yet another example of Microsoft currying favour with President Bone-spurs. I'm sure that inconveniencing us "nasty" Canadians earned dear Satya a few brownie points.
Re: (Score:2)
And he'll probably be jobless by the end of the week.
The biggest reason that was silly is because nobody actually thinks like that. Seriously, that was a dumb thing to say.
Actually is a hard problem, fault of politicians (Score:4, Insightful)
This is actually a much harder problem to address than it would seem. Obviously if the remote meeting event was in, say New York, and I find myself in a place where MDT is now year round, a simple time zone conversion is all that's needed and nothing breaks so long as the local client has an updated time zone list. But if the meeting was scheduled in a city that is now part of a different time zone, now it's off for everyone all over the world. And there's no easy way for the calendaring system to know the difference between those two scenarios. So we have a mess for sure, and it's a mess of a just a few politicians' making.
Re: Actually is a hard problem, fault of politicia (Score:1)
Re: (Score:2)
Yeah, it's a hard problem - because Microsoft isn't storing the time in UTC and using a display time to handle everything else. They must be storing in local time and doing conversions back and forth, making it unnecessarily complicated.
Re: (Score:3)
No that's incorrect. They are storing in UTC. That's not the problem. And it's not exclusive to Microsoft. I just saw the problem in Google Calendar as well. I have an appointment I recorded for next week at 6am. At the time I made the appointment, Google knew that I was in MST/MDT, and so when it stored the UTC time, it knew that the day of the appointment would have been MST (it was a distant future event before so-called alberta time was a thing). So it adjusted the time by one hour, converted it to
Paul Eggert fixed this last month (Score:2)
Microsoft, of course, refuses to use his excellent free work.
His fix has issues as well, but he kept the pain on the implementation side as best he could.
Re: (Score:3)
Yes that's the glib answer as I and others posted earlier. But if I understand correctly, updating the timezone definitions has very little to do with the actual problem, which is far more subtle. Consider you add an event to your calendar. The obvious thing to do is to convert the event to UTC so that it's just a matter of applying a tz offset and everyone all over the world see it properly. But for recurring events, the system has to apply hacks anyway to ensure that the recurrent event six months from
Re: Paul Eggert fixed this last month (Score:1)
Re: (Score:2)
Because people like to create recurring events that move with their timezone, e.g. weekly stupid meeting @ 4 pm every Friday.
The solution is to define the recurring event as a generator in the local timezone in which it was created, and use it to create actual events in UTC. If the user changes their timezone they have to decide whether they want to generator to remain as it is or be translated into the new timezone.
Re: (Score:2)
They certainly are in UTC in the database. Can you see the subtle problem? Hint it was caused by the standard/daylight savings change originally.
UTC (Score:2)
UTC everywhere, all the time and just be done with Timezones and DST forever!
Re: (Score:2)
Re: (Score:3)
People work after sunset and before sunrise all over the place. Some places are open 24/7. And yet, people manage it just fine. And some places are dark for large portions of the year, and bright for large portions of the year. It's almost like the world is a sphere or something and no two places are the same! Some places are summer at the same time other places have winter. Weird huh?
Re: (Score:2)
Won't fix this problem. MS and Google do use UTC in the back end to store the calendar dates and times. But events that were scheduled when I used to live in MST are now off by an hour now that my computer and phone are in permanent MDT. This is because the underlying UTC time is now off by an hour.
No accident! (Score:3, Funny)
It's all part of Commie-Canada's master plan to cripple America's tech industry and make the U.S. Canada's 13th Provence.
Wish I was in Canada (Score:2)
Wish I was living in Canada this week. I'd have all the excuses I need to "accidentally" miss meetings.
Not just MSFT (Score:3)
To be fair to Microsoft, not just them. My Google calendars also borked themselves. Control4 has absolutely no idea where my home is anymore. And one of my Claude Code routines has an absolutely hilarious little bit of soliloquy as it argues with itself about what time it's supposed to fire.
I guess we're still not well set up to create new time zones :)
It's an easy fix if people could pay attention (Score:2)
The "fix" for this is to ask everyone exactly what they are anchoring their event times to.
The problem with the easy fix is that asking people to carefully consider a question is generally impractical. Many people won't understand a question about time zones and won't understand the implications, meaning that there's almost no point in even asking.
Great, they cannot even get simple things right (Score:3)
It seems MS is regressing and getting worse and worse.
Re: (Score:2)
There is absolutely nothing simple about managing time zones. It only *seems* simple, because most of us spend all of our time in a single time zone. The minute you have to start calculating time offsets, things get hairy really fast. Different jurisdictions have different rules for things like when DST starts and ends, or if it is observed at all. In some cases, it requires you to know the precise place, to know what the rules are in that location.
Re: (Score:2)
There is. You read the standard, you implement the standard. And then you do an once-over over all time zones each year to check which standard they are following and if and when they are switching. Probably less than one competent engineer. But apparently, either MS does not have competent engineers or does not want to spend money on this. And hence they have a ton of egg on their faces. Again.
Re: (Score:2)
You've clearly never had to do any programming related to time zone offsets. And by that, I don't mean just doing arithmetic with DateTime objects. I mean, having to account for differences in time zones.
The IANA time zone database has 2,107 rules that specify how time zones are calculated. Updates to that database were release 6 times just this year. https://www.iana.org/time-zone... [iana.org] Now, add to that, software that has to correctly interpret these rules for its own purposes, and you've got a mess.
Windows 10 didn't seem to get an update either (Score:2)
I'm still running W10, in BC, and my computers all switched yesterday.
And there doesn't even appear to be an option to choose our 'new' timezone. So had to disable sync, and set time manually.
The dumb clocks on my oven and bathroom heater are smarter.
Oblig xkcd (Score:2)
https://xkcd.com/1883/ [xkcd.com]
There's a deeper problem (Score:2)
Some of the problems that have arisen here are not the fault of Microsoft or Google or other platforms because they are due to a deeper problem in setting times: times must be set with respect to a particular place - a time should be recorded as a pair of a time and a geographical anchor. Since calendars and other such problems generally do not do this, changes in the relationship between time zones can cause problems.
I participate in a seminar whose organizer is in Ann Arbor. It takes place at 2pm on Fr