[tz] tz database update on a publication & thank-you.

[Robert Elz]

    Date:        Thu, 30 Jul 2020 09:27:27 -0700
    From:        Steve Allen <sla at ucolick.org>
    Message-ID:  <20200730162727.GA30196 at ucolick.org>

  | For the sake of the software and that article I point out that the
  | nothing that could be called UTC existed before 1960,

All that's fine, but shouldn't really matter.

There was nothing called a "metre" before the late 18th century, but
it is still reasonable to measure the distance between the earth and
the moon (or other bodies) from millions of years ago, or the heights
of ancient mountains, in metres.  The fact that it wouldn't have been
called that (and even would have resulted in a different numeric value
using some other scale which might have existed at the time) doesn't
really matter.

For the data in question, the minor differences between GMT and UTC,
and even the various different UT and UTn's, and even TAI, don't matter
either - birth times would have been set by either looking at someone's
watch, or a wall clock, and the chance of those actually being "correct"
(within a minute or two, or three) aren't great (would not have been
great in the mid 20th century - even for doctors who could afford expensive
timepieces).

So, I wouldn't really get all pedantic and complain that a time in 193x/194x
couldn't possibly be UTC, as UTC didn't exist then .. what it means is
the time it would have been in UTC (or close enough for the purpose) had
it existed back then (and it has existed longer than the software that
generates these values I assume).

kre

ps: I still believe it is a big mistake to ever convert times expressed
in local time into some other timebase, and store that, instead of storing
the local time, and the timezone information.  The local time is the recorded
absolute value, which will never change - even if someone later realises that
the offset from UTC (or GMT) that's in the database happened to be incorrect
and fixes it.   But if you've stored just the UTC (or GMT) version, you no
longer really know whether that came from the old bad data or the new fixed
version (especially if you're not keeping a very close watch on every change
to the database - and even moreso if updates are automated and just happen
without anyone really being aware of it).