I do want to note: …isn't true with Windows, which actually does reset the hardware clock on DST changes.
I do want to note:
Unlike your microwave or your alarm clock radio, when you enter Daylight Saving Time, your computer’s internal clock doesn’t actually go forward or back one hour.
…isn't true with Windows, which actually does reset the hardware clock on DST changes.
This gave me headache. Admittedly I don't have any experience working in Microsoft's dev ecosystem, but it's kind of insane that the cause of the bug was identified, it seems like it would be...
This gave me headache.
The in-house-written logic that was written to emulate the .NET library, however, did no such thing. Instead, it subtracted 2 hours (Israel’s regular UTC offset) from the datetime object, and stuck the result in the XML. Easy. During non-DST times, this would work great.
Admittedly I don't have any experience working in Microsoft's dev ecosystem, but it's kind of insane that the cause of the bug was identified, it seems like it would be somewhat straightforward to resolve, and the powers that be still chose to leave the bug intact in favor of letting IT work around the issue. And like the solution they're using has so many more moving parts that it's bound to be more error prone than whatever programmatic fix they could sort out. There's no way that convoluted process went off without issue year after year.
I would guess that this custom serialization logic was widely-used, and the consequences of changing the behavior were in some cases known to be substantial, and in others not known. In that case,...
I would guess that this custom serialization logic was widely-used, and the consequences of changing the behavior were in some cases known to be substantial, and in others not known. In that case, there's a high cost to making the fix (you have to patch up dependencies you know about, put some effort into searching for dependencies you don't know about, and guess that you'll probably break some other stuff anyway), even if the actual fix is known. (That assumes inadequate test coverage, but… given the context, that's a safe assumption. =P)
It's still certainly the wrong decision (there are basically guaranteed to be other breakages that are just less obvious; this sort of thing increases the fragility of the codebase, which has compounding effects; and yeah, the operational overhead described is just ludicrous), but executives have a well-known bias towards choosing the shit situation they believe they understand over one they don't. So, yeah: ultimately, not surprising.
This was an interesting post, but the author is incorrect about how time is handled in Windows. By default Windows syncs the hardware clock to whatever the users local timezone indicates. Windows...
This was an interesting post, but the author is incorrect about how time is handled in Windows. By default Windows syncs the hardware clock to whatever the users local timezone indicates. Windows can be configured to do what Linux does which is sync the hardware clock to UTC and then use the timezone offset to adjust date/time displays however via group policy / registry hack.
I only know this from wasting years of time dual booting between Linux and Windows on the same hardware and having to configure one or the other upon reinstall to work in such a way that it would match what the other one was doing so as to avoid the hardware clock getting skewed as part of switching OSes.
The reality is that storing time as UTC is the correct approach, its DST that is abhorrently idiotic. Shifting times twice a year for precisely zero good reason is a tradition that needs to go out the window sooner rather than later.
The standard used by the hardware clock (CMOS clock, the BIOS time) is set by the operating system. By default, Windows uses localtime, macOS uses UTC, other UNIX and UNIX-like systems vary. An OS that uses the UTC standard will generally consider the hardware clock as UTC and make an adjustment to it to set the OS time at boot according to the time zone.
...
To dual boot with Windows, it is recommended to configure Windows to use UTC, rather than Linux to use localtime. (Windows by default uses localtime [2].)
I do want to note:
…isn't true with Windows, which actually does reset the hardware clock on DST changes.
This gave me headache.
Admittedly I don't have any experience working in Microsoft's dev ecosystem, but it's kind of insane that the cause of the bug was identified, it seems like it would be somewhat straightforward to resolve, and the powers that be still chose to leave the bug intact in favor of letting IT work around the issue. And like the solution they're using has so many more moving parts that it's bound to be more error prone than whatever programmatic fix they could sort out. There's no way that convoluted process went off without issue year after year.
I guess I'm not surprised, but like...damn.
I would guess that this custom serialization logic was widely-used, and the consequences of changing the behavior were in some cases known to be substantial, and in others not known. In that case, there's a high cost to making the fix (you have to patch up dependencies you know about, put some effort into searching for dependencies you don't know about, and guess that you'll probably break some other stuff anyway), even if the actual fix is known. (That assumes inadequate test coverage, but… given the context, that's a safe assumption. =P)
It's still certainly the wrong decision (there are basically guaranteed to be other breakages that are just less obvious; this sort of thing increases the fragility of the codebase, which has compounding effects; and yeah, the operational overhead described is just ludicrous), but executives have a well-known bias towards choosing the shit situation they believe they understand over one they don't. So, yeah: ultimately, not surprising.
This was an interesting post, but the author is incorrect about how time is handled in Windows. By default Windows syncs the hardware clock to whatever the users local timezone indicates. Windows can be configured to do what Linux does which is sync the hardware clock to UTC and then use the timezone offset to adjust date/time displays however via group policy / registry hack.
I only know this from wasting years of time dual booting between Linux and Windows on the same hardware and having to configure one or the other upon reinstall to work in such a way that it would match what the other one was doing so as to avoid the hardware clock getting skewed as part of switching OSes.
The reality is that storing time as UTC is the correct approach, its DST that is abhorrently idiotic. Shifting times twice a year for precisely zero good reason is a tradition that needs to go out the window sooner rather than later.
EDIT: Arch Wiki has a great summary of how the OSes handle this: https://wiki.archlinux.org/title/System_time