[conspire] Serving ads on a Mediawiki site

[Nick Moffitt]

On 09Oct2020 01:55pm (-0700), rogerchrisman at gmail.com wrote:
> For some reason, when I startup Windows 10 after a session running my
> desktop in Xubutu, the time of day is off by several hours and needs
> to be re-synched. Any idea why that is? I may have asked this question
> right here years ago. Time flys. I might have only imagined that.
> Thoughts fly, too. Little fly, been somewhere interesting? (Pence's
> head? Oh.)

Just off the top of my head, would you happen to be on the West Coast, and would the clock be off by 7 hours in the summer, and 8 hours in the winter?

If so, this is almost certainly because Windows uses local wall-clock time for the system clock, and actually updates the hardware clock when local time zones change (such as in the transition between Pacific Standard Time and Pacific Daylight Time during the "daylight savings" switchovers).

By contrast, Linux systems prefer to keep the hardware clock in UTC.  This allows people to ssh in from all over the world, and their $TZ environment variables will provide the offset from this reference time to produce local wall-clock time in their environment.  For example, if I were to ssh into your Xubuntu system from London, my $TZ value of "Europe/London" would set me to +0100 (British Summer Time), while your $TZ of "PST8PDT" or "America/Los_Angeles" would set it to -0700 for Pacific Daylight Time.

This is more about convention than technology.  It's perfectly possible to set up Linux systems so that the hardware clock uses wall-clock time, but it's been deprecated in favour of the UTC-plus-timezone-offset system.  Linux and its Unix forbears were always multi-user systems, while Windows got its start as a single-user desktop system.

Incidentally, the use of local wall-clock time for hardware used to have a preposterous side-effect during DST transitions: Windows systems left running at 2AM during the "fall back" change would automatically set their clocks back to 1AM, and then they'd do it again the NEXT time they reached "2AM".  And so on, to infinity...

I'm not sure how they sorted this out, but I'd imagine a simple "Did we last spring forward or fall back?" bit would be a reasonable workaround to this.  Personally I'd prefer not to introduce something as silly as legislated clock-fiddling to the lowest layer of my system, and keep it in a compatibility layer like the time zone system where it can be cheaply adjusted if the world ever comes to its senses about this nonsense.