[tz] How good is pre-1970 time zone history represented in TZ database?

[Robert Elz]

    Date:        Wed, 3 Jun 2020 16:02:45 +0100
    From:        Lester Caine <lester at lsces.uk>
    Message-ID:  <3b7f0c78-4dd7-0f2e-a8e3-2b24401e7e1c at lsces.uk>

  | To some extent I totally agree with you, but unfortunately many systems 
  | simply assume that there is never a problem with the TZ data so they 
  | don't need to store both values.

They don't in any case - the only one needed is the authoritative
timestamp, which is almost always local time, somewhere (occasionally
it might be UTC, but for most of us, that's rare - for astronomers perhaps
less so).

  | I came into this 20 years ago

I've been involved with it for longer than that - back to my first
unix experience, in '76, where the US tz rules were compiled into the
code, and most people in AU simply adjusted their computer's clock
(their offset from UTC) 4 times a year (when the US switched summer time
on and off, and when AU did - and yes, that meant that the generated GMT
timestamps were wrong, most of the time).   From that (a bit later) I was
responsible for the mess that existed until ado invented tzdata (and yes,
I mean the 2nd arg to gettimeofday()).

>From all of this I have learned that time is hard.   Really hard.

Many people believe that since they learned to tell the time when
they were 4 or 5 years old, and have been doing it ever since, they
know all there is to know.   That's sad...

  | now while working with a data archive 
  | which has now been simply dumped because we had no idea what rules were 
  | used to produce the normalised data.

That's a pity, byt sometimes past mistakes simply come back to bite,
and sometimes bite hard.   Note that the error there was normalising the
data, if that hadn't been done, none of the rest of it would matter,
you'd now have the original data and could manipulate it however seems
best, for now, regardless of what anyone did with it decades ago (and if
you get it all wrong, future generations could cope, because they'd also
still have the original data, and can fix any errors).

  | Nowadays yes it does make sense to 
  | store both an original time and a normalised time,

No, it doesn't, just the original, plus ...

  | along with a location,

yes, something which can be mapped into a timezone - and as accurate
a location as possible.

  | and a record of which version of rules was used to do the 
  | normalization.

Don't care about that, since the result won't be being saved.

  | Add to that a flag that indicates if the UTC time is fixed!

If the UTC time is the authoritative one, that is what is stored.
No need for extra flags.   Just the authoritative time - the one
which defines whatever it is that is being recorded.

  | Now with more virtual international meetings, the potential of
  | sessions moving an hour is not zero and being able to easily
  | identify that the recorded normalized time has now  changed

Here you're talking about current timestamps, and updates to the
rules.  If you need that kind of info, then as well as the authoritative
time, you can also store the "reported time" - then if a later
conversion generates something different, you can do whatever is
appropriate (but the recorded reported time is used only for that
comparison).

  | at a very minimum flags that you need to check if the local time 
  | now needs to change since the UTC time is fixed by the event calendar.

This kind of thing should be planned well into the future, with the
local times for several future meetings available to all to peruse
(whatever the base, or fixed, time is .. many of the meetings like this
that I've been involved with actually anchor the time to some US zone,
yes, parochial, but what that is is unimportant, as long as the auth
time and info leading to its zone are the primary source (and not some
conversion derived from that).

There will still be disruptions when time offsets change with little
notice, nothing much anyone can do about that except harangue whoever
is responsible for the problems they cause - but there's no good reason
that international e-meetings should be any better off than airlines, etc.

kre