[conspire] hardware clocks and ... (was: Serving ads on a Mediawiki site)

[Michael Paoli]

> From: rogerchrisman at gmail.com
> Subject: [conspire] Serving ads on a Mediawiki site
> Date: Fri, 9 Oct 2020 13:55:04 -0700

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

So, hardware clocks ... whether actual physical on the hardware,
or emulated, such as for Virtual Machine (VM) environments.

Bit 'o background/history - and in approximate chronological order.

Once upon a time ... UNIX ... and UNIX required a hardware clock.
Most notably so that when the system booted, it knew what time it was
(at least to a reasonably correct approximation).  And the hardware clock
kept time in GMT0/UTC - or at least some form reasonably easily
converted to such ... and then to UNIX system time - seconds since the
UNIX epoch (1970-01-01T00:00:00Z).  And for the mere mortal humans,
UNIX generally quite well took care of converting between system time,
and much more human friendly times, depending upon the user(s) timezone(s).
There would or may be a default for the system - generally GMT0 if not
otherwise set (though I've seen some UNIX flavors default out-of-the
box to EST5EDT ... I'm guessing probably from too many US government
purchase contracts).  Anyway, besides any set/configured system default,
users could also set TZ in the environment to configure their timezone
to their preference.  And all was well and good (or close enough).

Then along came Microsoft and IBM PC and PC AT and clones and the general
hardware families/compatibility that followed - your basic x86 PC family.
Initially before AT, there by default wasn't a hardware clock.  One would
need to manually tell the Operating System (OS) the correct time - at least
to get the correct time ... until rebooted, anyway.  And some hardware
clocks and related software came along - so one wouldn't have to do that
manually, ... and AT and later had a built-in hardware clock.  But
Microsoft MS-DOS and the like on that x86 hardware, went a different
way regarding time and system time and (later) hardware clocks.
Initially - the time is local - period - you set it to whatever it is
where you are ... and the hardware clocks were expected to be likewise
set.  As Microsoft OSs developed, they later added support of timezones
and such ... but the hardware clock discipline/convention mostly
remained the same - hardware clock set to local time - period.
And, when one changed timezones ... it would correspondingly change the
hardware clock's time to that new local time.  And, changing between
Standard and Daylight Saving time, or Standard and Summer times,
earlier had to manually change the hardware clock (and at least
generally OS's system time at the same time - at least with the OS up
and running).  Not sure how Microsoft subsequently deals with multiple
simultaneous users and timezones ... and if they can even simultaneously
have different timezones on same host at same time, but ... whatever,
OffTopic (OT).

Meantime UNIX and the like ... UNIX, Xenix, ... BSD, ... Linux ...
it gets ported to x86 hardware, and yes, requires a hardware clock
(or at least is a bit funky and problematic without - at best ...
e.g. without a working/available hardware clock, some would outright
fail to even boot (or at least to multi-user state), or would default to
the UNIX epoch, or would default to the last sync time found on the
root filesystem when going to mount the root filesystem or slightly
before that.

Anyway, UNIX and Microsoft, very different handling of hardware clock,
notably GMT0 vs. local time, respectively.  But as UNIX-like OSs got
ported to x86 ... which clock discipline?  That depended upon which
port.  Some went the UNIX way, some the Microsoft "way"/convention,
and some (e.g. Linux) developed support for either.

So, if one jumps between OSs on the same hardware (e.g. Microsoft vs.
Linux), there may be issues there - as they may handle the hardware
clock differently - or may be configured to do so.  This also applies
to VMs (at least in general - e.g. with full hardware virtualization) ...
though with VMs, the hardware clock is virtual, and so can be set to a
different time than the physical hardware clock.  But by default they
will generally be (or at least start off with) the same time on each.
VMs will generally track and preserve the offsets.  Some VMs may
allow configuring a default offset/discipline, or even have options
as straight-forward as default the VM clock to GMT0/UTC, or default
it to system default (typically local) time(zone).

Anyway, if your OSs are using the same hardware clock or same hardware
clock time, but have different behaviors on how they handle that - notably
GMT0 vs. local (except when those happen to align), one will generally
have issues.

There's also the issue of changing between
Standard and Daylight Saving time, or Standard and Summer times.
Most of the more modern OSs take care of that quite automagically.
And in the case of hardware clock discipline that's local, that means
OS changing the hardware clock when those transitions occur, and the
OS will generally track that it's made that update - so it can figure
out if it still needs to do so - and make that update (e.g. if the
host was down during the transition).  But with mutiple OSs, e.g.
dual boot, which one is responsible for changing the hardware clock
across such transitions?  Well, if they both think the hardware clock
should be local time, generally they'll both think they're responsible
for it, and each of them - when they have access (e.g. up and running)
will transition the clock - so that can, e.g. also result in double
shifting of the hardware clock.

Anyway, I think hardware clock to GMT0/UTC is the much more sane approach.
None of that changing the clock due to timezone changes or the like,
just convert to/from whatever time is preferred by the user, as they
configure, and likewise system default timezone.  And nobody has to
track who is responsible for and changed the hardware clock to go
between
Standard and Daylight Saving time, or Standard and Summer times.
And, heck, think of the frequent traveler with laptop ... gonna be mucking
with the hardware clock all over the place if it's local time discipline.
And what if that traveler does dual/multi-boot of various operating sytems
on that laptop?  Egad.

Anyway, Linux is pretty flexible and can well handle it either way.
Microsoft ... eh, I don't think so much so.  But I think that's an
easy fix - get rid of Microsoft.  ;-)
But yes, in any case, if all agree on GMT0/UTC for hardware clock,
things generally play much nicer together.  Otherwise things get
messier.  You can have Linux and Microsoft both handle as local,
but then you have to deal with their squabbles about who's top dog
when it comes to updating that clock, e.g.
Standard and Daylight Saving time, or Standard and Summer times
transitions ... and they'll both more than happily both do it for
you ... which is bit of an issue.
And maybe some hardware clocks handle this better ... but most of the
more basic AT and successor clocks, I don't think do - they've
generally got no concept of timezones or
Standard and Daylight Saving time, or Standard and Summer times
transitions ... and they'll both more than happily both play top dog,
and both implement those jumps forward and back ... and having no clue
if the other OS already did so or not.