This means that Western Ontario (aka Kenora) was wrong in tzdata between September 22nd and October 13th. tzdata usually includes Kenora in America/Winnipeg, but when Winnipeg decided to go to permanent daylight, Kenora and the rest of Western Ontario was left behind leaving a strange and ambiguous situation that wasn't clarified until October 13th. If the Ontario government wouldn't have done the right thing at the last minute tzdata would have had to do something like resurrect the America/Rainy_River time zone.
Albertan here. The problem wasn't just rolling out the changes (and needing staff to actually install updates and restart).
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.
> 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 thought using the city (America/Edmonton or America/Vancouver) does both of these though?
If someone in Alberta discussed a meeting with someone in Britain "let's say 12:00 London time" and the Albertan recorded that as 05:00 in their own calendar, then how can the software know that this should now be 06:00?
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.
it seems an unsolvable problem either way, the meeting is "at 12:00 london"
1. the London person owns it, schedules in local (London) time 12:00
2. the London person owns it, schedules mental math explicit Alberta time 05:00
3. the Alberta person owns it, schedules in local (Alberta) mental math time 05:00
4. the Alberta person owns it, schedules in explicit London time 12:00
You cannot get all of these working by software only no matter what you do, because there "mental math" time cannot take into account the implicit expectations, 1 and 4 will be correct as stated (the meeting is at 12 London time) but 2 and 3 what do you do? How would you differentiate between "mental math what I thought Alberta time was" vs "I really meant it at this Alberta time"
The problem you are describing is solved by saving/persisting times in UTC. The calendar will display the event by using the user's current timezone and the UTC time to determine local time.
You can store times in UTC if you want, but that alone doesn't solve the problem.
A UTC timestamp alone is not enough information about an event.
Consider a Doctor's appointment for Dec 20, 2026 2pm in Calgary. Regardless of whether its booked a year ahead (ie before the new time zone rules were decided) or a week ahead (after the rules were decided, and consequently a different UTC time), the expectation is that it will be at at 2pm local time.
But doing that breaks the opposite (and more common) problem: all the meetings in Alberta, planned before the change to the time zone was announced, will have the wrong hour.
I still choose the "America/New_York" / "Eastern Time (U.S. and Canada)" time zones when setting up systems in Indianapolis because "America/Indiana/Indianapolis" / "Indiana (East)" adds nothing but the possibility of error.
Indiana started observing DST in 2006. Bad memories die hard.
Its not that hard to get right. I'm a software dev working in Vancouver and our team was able to track all our timezone dependencies and account for the new offset. The Microsoft team definitely has some organizational issues since they've had 7ish months to fix this.
Describing it simply as "the new offset" seems like an oversimplification.
Just in BC there were multiple changes, some of which (eg Eastern Kootenays) were decided much more recently than 7 months ago. The MSTNO area didn't change, but in not changing its offset relative to the rest of the province did.
Displaying historical data, ranges that include the moment that the new definitions come into effect, temporal and/or spatial aggregations that span multiple timezone definitions... lots of tricky things can pop up.
That's not to excuse Microsoft. This isn't the first timezone change that has happened, and they should have the most robust change management process in the world for stuff like this.
US timezones also get messed with. This isn't a Canadian problem (in fact, many Canadian jurisdictions have laws on the books to automatically get rid of the switchover when enough US jurisdictions in the same timezone do it). The only truly unique Canadian time zone is Newfoundland, which is in it's own timezone that's off by half an hour as anybody growing up watching Canadian TV knows (X show at 8PM, or 8:30 in Newfoundland...).
I remember the shitshow in the mid 2000s when the Bush administration moved the time change cutover dates by 2 weeks as an attempt to deal with high energy prices (it didn't do much as lighting was by then a small percentage of electricity use and this was before LEDs). All sorts of machines needed updating, from ancient mainframes to clocks and watches, many of which couldn't. We Canadians also did it for longer term practical reasons.
Energy prices weren't even that high. Oil was in the the $50 range per barrel for the year, and the change didn't even go through until 2007. The main reason they did it was to make it so Halloween had longer daylight hours, so they could sell more candy.
I'm genuinely curious as to how fast this was handled by Apple devices, Linux, etc. With enough advance notice, I don't see this being that terrible to patch. Was it lack of advance notice?
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.
I'm in AB and work at a Windows/MS-based shop, and haven't run into any real problems with any Windows/Apple/Linux systems with the time change.
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.)
No issue at all for Manitoba time (or Saskatchewan time) on Linux devices. Teams in a browser (Linux) failed though, badly - so this is a systemic Microsoft problem.
I am also curious to know if having the system clock in UTC and storing times using UTC, which I understand UNIX-based operating systems do, avoids these types of issues. It should make them easier to manage, is my guess.
For past events, you can certainly store them as UTC and (possibly implied) location, provided that you also have a historically accurate database of all past time zone changes, so that you do not report that a meeting took place at 9:00 when it actually happened at 10:00, but the current time zone rules (at that location) are not the same today as they were on that date in the past.
For future events, you have to store them as location + timezone-naive dates and times, a.k.a. local time. Since if a meeting at a certain location is scheduled at 9:00, which is currently at 02:00 UTC, and then a timezone change happens, and UTC 2 suddenly means 10:00 at that same future date and location, the meeting will still happen at 9:00 local time. You cannot store future events as UTC only.
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.
UTC brings its own batch of problems when it comes to local time relative scenarios.
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.
Either UTC or TAI should be used for anything that is truly a "time".
The "time" at which future events are scheduled by humans (i.e. not the time when future events are predicted, like astronomical events), is not a "time", but it is a different data type, which must have a different name and which must store different information (i.e. legal date and time at a certain location).
As another poster already said, UTC is the correct choice for any kind of timestamps and for the storage of any time information about the past. (Actually TAI is an even better choice for these purposes.)
For future events, the "time" when they will occur is not "time", but a different data type, which should be called "legal time", "local time" or the like.
The "local time" for future events must include the geographic location attached to the event, from which the applicable time zone can be derived, at a time close to when the event is due.
my experience on apple devices in alberta hasn't been any better, microsoft is just the bigger target for articles like this because more people use it for scheduling meetings.
it took around 40hrs for my apple watch and my iPhone to start agreeing on what time it was.
We have Yoto devices for our kids and they haven't updated either, their America/Vancouver timezone fell back an hour last weekend. There is no UTC-7 or the proper Pacific time timezone. Frustrating, this was known for so long.
That stupid "special" timezones in Canada messed up Microsoft (they got their issues for not keeping their record stragith).
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.
> US should also abolish stupid daylight savings, but northern politicians do not want while there is bipartisan agreement to make the savings time permenant.
That bipartisan agreement will evaporate after the first winter on permanent DST and either DST will come back or we'll switch to permanent standard time. That's what usually happens when people try permanent DST.
Saskatchewan has been on permanent DST for a few decades now and no sign of them planning to go back. (They call it standard time, but it is standard for one timezone over, so effectively DST for their geographical location).
The tz commits:
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...
Microsoft doesn't use tzdata
This means that Western Ontario (aka Kenora) was wrong in tzdata between September 22nd and October 13th. tzdata usually includes Kenora in America/Winnipeg, but when Winnipeg decided to go to permanent daylight, Kenora and the rest of Western Ontario was left behind leaving a strange and ambiguous situation that wasn't clarified until October 13th. If the Ontario government wouldn't have done the right thing at the last minute tzdata would have had to do something like resurrect the America/Rainy_River time zone.
Sounds like money doesn't fix https://xkcd.com/2347 for Microsoft then.
Albertan here. The problem wasn't just rolling out the changes (and needing staff to actually install updates and restart).
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.
> 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 thought using the city (America/Edmonton or America/Vancouver) does both of these though?
If someone in Alberta discussed a meeting with someone in Britain "let's say 12:00 London time" and the Albertan recorded that as 05:00 in their own calendar, then how can the software know that this should now be 06:00?
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.
it seems an unsolvable problem either way, the meeting is "at 12:00 london"
1. the London person owns it, schedules in local (London) time 12:00
2. the London person owns it, schedules mental math explicit Alberta time 05:00
3. the Alberta person owns it, schedules in local (Alberta) mental math time 05:00
4. the Alberta person owns it, schedules in explicit London time 12:00
You cannot get all of these working by software only no matter what you do, because there "mental math" time cannot take into account the implicit expectations, 1 and 4 will be correct as stated (the meeting is at 12 London time) but 2 and 3 what do you do? How would you differentiate between "mental math what I thought Alberta time was" vs "I really meant it at this Alberta time"
The problem you are describing is solved by saving/persisting times in UTC. The calendar will display the event by using the user's current timezone and the UTC time to determine local time.
You can store times in UTC if you want, but that alone doesn't solve the problem. A UTC timestamp alone is not enough information about an event.
Consider a Doctor's appointment for Dec 20, 2026 2pm in Calgary. Regardless of whether its booked a year ahead (ie before the new time zone rules were decided) or a week ahead (after the rules were decided, and consequently a different UTC time), the expectation is that it will be at at 2pm local time.
Generally speaking, UTC + localization works for past events, but not future ones (see sibling comments)
But doing that breaks the opposite (and more common) problem: all the meetings in Alberta, planned before the change to the time zone was announced, will have the wrong hour.
Using city name references (alberta/edmonton) rather than Mountain Time is correct in all cases.
I still choose the "America/New_York" / "Eastern Time (U.S. and Canada)" time zones when setting up systems in Indianapolis because "America/Indiana/Indianapolis" / "Indiana (East)" adds nothing but the possibility of error.
Indiana started observing DST in 2006. Bad memories die hard.
Its not that hard to get right. I'm a software dev working in Vancouver and our team was able to track all our timezone dependencies and account for the new offset. The Microsoft team definitely has some organizational issues since they've had 7ish months to fix this.
Describing it simply as "the new offset" seems like an oversimplification.
Just in BC there were multiple changes, some of which (eg Eastern Kootenays) were decided much more recently than 7 months ago. The MSTNO area didn't change, but in not changing its offset relative to the rest of the province did.
Displaying historical data, ranges that include the moment that the new definitions come into effect, temporal and/or spatial aggregations that span multiple timezone definitions... lots of tricky things can pop up.
That's not to excuse Microsoft. This isn't the first timezone change that has happened, and they should have the most robust change management process in the world for stuff like this.
[flagged]
US timezones also get messed with. This isn't a Canadian problem (in fact, many Canadian jurisdictions have laws on the books to automatically get rid of the switchover when enough US jurisdictions in the same timezone do it). The only truly unique Canadian time zone is Newfoundland, which is in it's own timezone that's off by half an hour as anybody growing up watching Canadian TV knows (X show at 8PM, or 8:30 in Newfoundland...).
I remember the shitshow in the mid 2000s when the Bush administration moved the time change cutover dates by 2 weeks as an attempt to deal with high energy prices (it didn't do much as lighting was by then a small percentage of electricity use and this was before LEDs). All sorts of machines needed updating, from ancient mainframes to clocks and watches, many of which couldn't. We Canadians also did it for longer term practical reasons.
Energy prices weren't even that high. Oil was in the the $50 range per barrel for the year, and the change didn't even go through until 2007. The main reason they did it was to make it so Halloween had longer daylight hours, so they could sell more candy.
ok tough guy
> I would've deleted all Canada timezones out of spite
Out of spite at what?
Canada
>Canada
Why, specifically?
I'm genuinely curious as to how fast this was handled by Apple devices, Linux, etc. With enough advance notice, I don't see this being that terrible to patch. Was it lack of advance notice?
Date decision announced:
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.
I'm in AB and work at a Windows/MS-based shop, and haven't run into any real problems with any Windows/Apple/Linux systems with the time change.
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.)
The OS knows how to handle all sorts of weird timezones without issue. On mac it's just a matter of updating the files in /usr/share/zoneinfo/
No idea what Microsoft is doing.
They're vibecoding.
No issue at all for Manitoba time (or Saskatchewan time) on Linux devices. Teams in a browser (Linux) failed though, badly - so this is a systemic Microsoft problem.
The TZ db team have been aware of this since the first announcement in BC.
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.
I am also curious to know if having the system clock in UTC and storing times using UTC, which I understand UNIX-based operating systems do, avoids these types of issues. It should make them easier to manage, is my guess.
For past events, you can certainly store them as UTC and (possibly implied) location, provided that you also have a historically accurate database of all past time zone changes, so that you do not report that a meeting took place at 9:00 when it actually happened at 10:00, but the current time zone rules (at that location) are not the same today as they were on that date in the past.
For future events, you have to store them as location + timezone-naive dates and times, a.k.a. local time. Since if a meeting at a certain location is scheduled at 9:00, which is currently at 02:00 UTC, and then a timezone change happens, and UTC 2 suddenly means 10:00 at that same future date and location, the meeting will still happen at 9:00 local time. You cannot store future events as UTC only.
That's not a major factor in this, afaik.
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.
UTC brings its own batch of problems when it comes to local time relative scenarios.
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.
That's interesting because I work in industrial data and pretty much everything is stored and logged as UTC to avoid these kinds of mess ups.
Either UTC or TAI should be used for anything that is truly a "time".
The "time" at which future events are scheduled by humans (i.e. not the time when future events are predicted, like astronomical events), is not a "time", but it is a different data type, which must have a different name and which must store different information (i.e. legal date and time at a certain location).
As another poster already said, UTC is the correct choice for any kind of timestamps and for the storage of any time information about the past. (Actually TAI is an even better choice for these purposes.)
For future events, the "time" when they will occur is not "time", but a different data type, which should be called "legal time", "local time" or the like.
The "local time" for future events must include the geographic location attached to the event, from which the applicable time zone can be derived, at a time close to when the event is due.
my experience on apple devices in alberta hasn't been any better, microsoft is just the bigger target for articles like this because more people use it for scheduling meetings.
it took around 40hrs for my apple watch and my iPhone to start agreeing on what time it was.
We have Yoto devices for our kids and they haven't updated either, their America/Vancouver timezone fell back an hour last weekend. There is no UTC-7 or the proper Pacific time timezone. Frustrating, this was known for so long.
That stupid "special" timezones in Canada messed up Microsoft (they got their issues for not keeping their record stragith).
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.
> US should also abolish stupid daylight savings, but northern politicians do not want while there is bipartisan agreement to make the savings time permenant.
That bipartisan agreement will evaporate after the first winter on permanent DST and either DST will come back or we'll switch to permanent standard time. That's what usually happens when people try permanent DST.
Saskatchewan has been on permanent DST for a few decades now and no sign of them planning to go back. (They call it standard time, but it is standard for one timezone over, so effectively DST for their geographical location).
That's a whole lot of stupid!
- Regional time zones? Stupid.
- One time zone for the entire nation? Stupid.
- Daylight Savings Time? Stupid.
- When Western Canada gets rid of DST? You guessed it... stupid!
Everything is stupid!
i call dumb sh*ts dumb and what's the issue?
Did i say everythign is stupid? No. I only showed the part of the issues.
You went down the slippery slope went extreme.
Let's get rid of time!
even more extreme slippery slope. you are like the one who say get rid of cars because they kill people.
Let's get rid of time because it kills people.