[conspire] Ti-i-i-ime, is on my side, yes it is

[Michael Paoli]

Well, not sure exactly what the letter of the law says, but ...

For Linux, and more generally Unix, BSD, POSIX(, ...?), things are
handled relatively automagically*.

$ zdump -v US/Pacific | fgrep 2020
US/Pacific  Sun Mar  8 09:59:59 2020 UT = Sun Mar  8 01:59:59 2020 PST  
isdst=0 gmtoff=-28800
US/Pacific  Sun Mar  8 10:00:00 2020 UT = Sun Mar  8 03:00:00 2020 PDT  
isdst=1 gmtoff=-25200
US/Pacific  Sun Nov  1 08:59:59 2020 UT = Sun Nov  1 01:59:59 2020 PDT  
isdst=1 gmtoff=-25200
US/Pacific  Sun Nov  1 09:00:00 2020 UT = Sun Nov  1 01:00:00 2020 PST  
isdst=0 gmtoff=-28800
$

For us US DST folks using such local time, up to 2:00 AM occurs,
but 2:00 AM doesn't, being replaced instead by 3:00 AM.
Or, more precisely, that's what the system time (measured in systems
since the epoch) is converted to for us by mere mortal humans.

And, as for most things digital electronic that follow DST (and the
like), they generally do likewise - up to time of change, use the
transitioning from (e.g. PST), and at and beyond, use the transitioned
to (e.g. PDT).  Such devices also do generally same with AM/PM and
date - noon as PM, midnight as AM and midnight itself the new day,
not the old.  But technically things may be a bit different.
E.g. noon and midnight, technically neither AM nor PM.  But our
digital devices generally don't allow for a third state - even for
infinitely small but existent amount of time.
Likewise, midnight ... belongs to which day?
In many practices, to avoid confusion/ambiguity, when precisely midnight
is intended, 00:00 is given as the one at start of day, and 24:00 for the
one at end (well, if you can stretch a bit to have midnight belong to
both days, rather than neither).

Ah, ... and then we get to leap seconds ... perhaps for another time,
things get even more interesting there.

*well, not quite.  For all the dang timezones around the world, and
all the relevant governing bodies, and they're mucking about with
various local and regional clocks, there's a relatively constant
influx of changes - typically many per year or more.  So, there's a
fair bit of work done maintaining the timezone files ... at least by some.
And, mostly thanks to their work, for most all of us - further down
the chain, it's mostly a simple matter of generally quite easily applying
the updates to the timezone files.  That's generally covered along with
regular security and maintenance updates, so overall, the additional
overhead is rather to quite slight.

> Received: from rick by linuxmafia.com with local (Exim 4.72)
>         (envelope-from <rick at linuxmafia.com>) id 1jAskA-0004FX-2n
>         for conspire at linuxmafia.com; Sun, 08 Mar 2020 03:01:10 -0700
> Date: Sun, 8 Mar 2020 03:01:10 -0700
> From: "Rick Moen" <rick at linuxmafia.com>
> To: conspire at linuxmafia.com
> Subject: [conspire] Ti-i-i-ime, is on my side, yes it is
> Date: Sun, 8 Mar 2020 03:01:10 -0700

> This message is being sent at 2:00 AM, which is exactly the same as 3:00
> AM.  I hope that clarifies matters completely.
>
> (Spring forward.  Fix those clocks.)