That said, operating systems need to get the correct files in place.
Edit here's the TZ Announce list. Note that Cuba's very recent decision not to leave DST is included.
A) you need the new timezone definition available and pushed everywhere regardless. It doesn't matter what zone the RTC uses.
B) For future events, you need a way to manage what happens when the time zone they're scheduled in changes OR when they change to a new time zone. Microsoft has been terrible at this part on every time zone change I've been aware of (it's hard, but it's not this hard, and the Canadian change was published with sufficient notice, and time zone changes happen for recurring events, this is not a new requirement). But there's no connection to the time zone of the RTC here either.
If you have issues with poor behavior specifically around transitions, that could be related... Repeatedly moving forward or backward for DST is something where keeping the RTC in UTC would help.
Last time I looked best practice for a real calendar app was to store in local time with time zone, not UTC with offset.
UTC is time in theory. Points in time separated by numbers of seconds. Great until the reality of time being a social construct breaks your assumptions. Still, use UTC until you are actually building a calendar app. Depending on your use case, consider storing timezone instead of offset.
No idea what Microsoft is doing.
Our IT department ran a couple scripts last week and everything this week has been smooth sailing.
Things I have run into problems with have been my smart thermostat (ecobee, now fixed), my Philips Hue lights (most of my automations are via Home Assistant, but I have a handful that rely on colour temp in the Hue app), and my Ford car. (Auto time zone and auto time aren't separately configurable, and auto time zone puts me in the wrong time zone.)
BC: March 2 Alberta: April 20 Manitoba: Sep 17 Western Ontario: Oct 13
Manitoba didn't give much advance warning. Western Ontario is on the same time zone as Manitoba so it was very confusing there until at the last second it was clarified. So Microsoft has an excuse for screwing up Kenora. Vancouver though should not have been a problem.
it took around 40hrs for my apple watch and my iPhone to start agreeing on what time it was.
Even if you update your Windows settings to say the new correct time zone, it still doesn't go back and update the time zone that future Outlook meetings are scheduled for.
I noticed that my personal calendar on my phone seemed fine, and iOS seems to book meetings based on a TZ identifier (America/Edmonton) rather than offset or a name like 'Mountain Time.' That system seems to have worked well in this case.
It's tricky, do you want future meetings to follow the city they're in, or do you want past meetings to properly track when they happened across zone redefinition (and what even is correct)? There's no simple way to get this right everywhere.
I still think the path Outlook took wasn't ideal for the majority of their customers in the effected places though.
I thought using the city (America/Edmonton or America/Vancouver) does both of these though?
The Albertan could have set the time to 12:00 in Europe/London, but probably few people do this unless they're expecting to travel to the other place.
September 22 for Manitoba https://github.com/eggert/tz/commit/cd706278466a3ad431f0ad39...
July 8 for Alberta: https://github.com/eggert/tz/commit/ddcb5fa20791c3c5f1a15194...
April 22 for British Columbia: https://github.com/eggert/tz/commit/8b46071fd85a7a9434d63894...
yipinwong•50m ago
This is what happens when a part of country does not follow. China is the other extreme. They got one stupid timezone, so one part of the country is dark AF, but then other side is daylight.
This all comes down to whoever is running the government.
US should also abolish stupid daylight savings, but northern politicians do not want while there is bipartisan agreement to make the savings time permenant.