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