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?

▲ bryanlarsen 10 hours ago | parent | next [-]

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.

▲ Marsymars 10 hours ago | parent | prev | next [-]

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.)

▲ teunispeters 9 hours ago | parent | prev | next [-]

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.

▲ itslennysfault 10 hours ago | parent | prev | next [-]

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.

	▲	AlexandrB 9 hours ago \| parent [-]
		They're vibecoding.

▲ gerikson 10 hours ago | parent | prev | next [-]

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.

▲ byte_0 10 hours ago | parent | prev | next [-]

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.

▲ teddyh 9 hours ago | parent | next [-]

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.

▲ toast0 10 hours ago | parent | prev | next [-]

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.

▲ kayodelycaon 10 hours ago | parent | prev [-]

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.

▲ JTbane 9 hours ago | parent | next [-]

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.

  best practice for a real calendar app was to store in local time with time zone, not UTC with offset

	▲	adrian_b 8 hours ago \| parent [-]
		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).

▲ adrian_b 8 hours ago | parent | prev [-]

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.

▲ notatoad 9 hours ago | parent | prev [-]

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.