Some Apple Watch Series 4 Models Are Frequently Crashing and Rebooting Due to a Daylight Saving Time Bug (macrumors.com)

Some Apple Watch Series 4 owners in Australia experienced crashes and reboots on Saturday due to a bug that surfaced because of the daylight saving time change. From a report: According to Reddit users hit by the Apple Watch bug, the root of the problem appears to be the Infograph Modular face's Activity complication, which displays a timeline graph with hourly data for the user's Move calories, Exercise minutes, and Stand hours. When daylight saving time (DST) lops an hour off the typical 24-hour day, the Activity complication is apparently unable to compute the change and draw the timeline graph with only 23 hours, which throws the Apple Watch into an endless reboot loop until the battery runs out.

Comments

Whoopsie

[war4peace]

One more reason to do away with that monstrosity called DST”.

Re:Whoopsie

[ledow]

But you'd rather these people who can't use long-established timezone libraries, handling protocols and data formats did things like monitor your heart rate and ran your car instead?

The problem here is not DST or the complexity of it... if that were the case the banking industry, Internet, phones, etc. would fall over at the same time because of the same problems.

The problem is that someone at Apple doesn't understand how to handle dates properly despite there being long-established libraries for exactly that. And they didn't bother to check (i.e. test) adequately enough before releasing millions of dollars of mass-market products.

The problem is lax development and testing. Not the complexity of handling something that billions of devices owned by billions of people around the world handle every year just fine.

Re:Whoopsie

[angel'o'sphere]

Well, from one point of view you are right.

However, as I worked quite a long time in the energy business: DST is a pain in the ass. Not only because of programmers making mistakes (I would not call that incompetent ... what again are the rules for a leap year? Are you sure you know them all? It is only 2 rules, though, or 3, depending how you count)

Mistakes are also made in the requirements/business analysis. And if a programmer says: "uh, that does not look right" often he gets stared down and challenged: who are you to know better than me.

Regarding "energy business": You have every day a kind of spread cheat with 24 hours as columns down. For every power plant you have 4 rows, planned power production for every quarter hour.

Two days of the year are an exception. One day has 23 columns, one has 25.

Then again if you e.g. want to sent power from Germany to France or to Poland, you have to prepare a "schedule" for your grid feed in, 24h ahead (erm, 23h? 24h? 25h?).

The grid operator is working his grid, similar as pointed out above, with 24h columns and his balancing/reserve power plants according to the schedule. But: two times in the year the schedule has not 24 but 25 or 23 columns.

One unix idiot ... idiot because I considered him a friend, until he started bullying me in some jobs ... once said: "it is so easy! Just schedule everything in UT!" What he did not grasp is: everything is scheduled in UTC. But you nevertheless want one day in the year to see your whole day as a 25h day, and the other day in the year you want to see your whole day as a 23h day ...

It is quite important that my French or my Polish power company friends agrees that we are at 2:00A or 2:00B at night for a power feed into the grid.