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.

▲

subarctic 10 hours ago | parent | next [-]

> 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?

▲

Symbiote 10 hours ago | parent | prev | next [-]

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.

▲

tetraodonpuffer 9 hours ago | parent | next [-]

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"

▲

mrpotato 8 hours ago | parent | prev [-]

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.

	▲	rjrjrjrj 7 hours ago \| parent \| next [-]
		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.
	▲	jessekv 7 hours ago \| parent \| prev \| next [-]
		Generally speaking, UTC + localization works for past events, but not future ones (see sibling comments)
	▲	Symbiote 8 hours ago \| parent \| prev [-]
		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.

▲

freeone3000 10 hours ago | parent | prev [-]

Using city name references (alberta/edmonton) rather than Mountain Time is correct in all cases.