1. 14
  1. 5

    Interesting if god-awful reasoning behind Windows setting the hardware clock to localtime.

    1. 8

      It’s not awful; it’s human-centric as our tools should be. Let the OS work a little harder so the system makes sense to the user even if they drop to a lower level.

      1. 5

        It isn’t human-centric, it’s pointlessly difficult: Most humans aren’t using the BIOS time, and the ones who are don’t want the problems inherent with trying to keep BIOS time on local time.

      2. 6

        Chen is always interesting and I sympathetic with Microsoft’s problems (apps love bad practices, but need to keep working, while keeping the system secure), sometimes it feels he’s reaching at straws to retroactively justify a bad decision.

        1. 5

          Other than compatibility with operating systems that set the hardware clock to UTC, why is it a problem?

        2. 4

          And now: Why The Way You’re Doing It Can’t Possibly Work

          The DOS Think way of keeping time is how time and timezones are managed in MS/PC/DR-DOS: The hardware real-time clock runs in local time, with daylight savings time adjustments, for one system-wide timezone, applied on the fly by the operating system (or manually twice a year by the system administrator). It is fundamentally and irredemably flawed. Nonetheless, people still use it even now. It’s still the thinking as employed by Windows NT, for example.

          It lists two basic problems:

          The first basic problem: There’s no universally recognized flag for recording the current standard/daylight savings time state.


          The second basic problem: The hardware clock yields values that are ambiguous or outright impossible for local time.

          1. 3

            While this is the default, behaviour can be made sane:


            1. 2

              Thanks. I dual boot Windows and Arch on my laptop. Never thought to check if I could fix Windows.