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

[Lester Caine]

On 31/07/2020 00:51, Paul.Koning at dell.com wrote:
>> On Jul 30, 2020, at 6:41 PM, Robert Elz<kre at munnari.OZ.AU>  wrote:
>>
>> ...
>> 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).
> True, assuming the common case where the original time reading was from a clock set to local time.  In some cases people would be using clocks set to another standard, such as GMT or the time of some other standard meridian.  If you're looking at timestamps from the chronometer era of sailing, the reference time is that of the chronometer, which is set to GMT, or Paris time, or Washington time, etc., depending on the ship.
> 
> Similarly, astronomical records might be given in GMT.  Or even local sidereal time, which really makes things fun.

I can into this as the result of trying to sort out historic data that 
had been 'normalised' but nobody had recorded the critical piece of 
information ... what version of TZ data had been used to normalize it. 
It was FURTHER complicated because the 'local time' of the server 
hardware had been used as part of the process again without any record 
of what set of rules was actually used!

Totally accept these days that the recorded data should be the recorded 
time and SEPARATELY record the LOCATION where the time was recorded. 
Even today there are arguments about just what 'timezone' is being used 
locally :( so it would be helpful to record the 'timezone' as a third 
piece of data.

But the other part of the jigsaw is still to run any international web 
based system on UTC so that the 'local time' of a server does not come 
into the equation. When I am posting to some forums that still don't 
understand the problem they give a post time I do not recognise and when 
looking back through emails times can be out of sync. And they still 
assume the 'timezone' provided by my browser is a timezone when it's 
only ever a current offset ... TODAY it is more than likely that the 
time of birth of a baby will be recorded electronically ... on a 
computer system ... where several local times are being used and the 
sequence of records are best served by using UTC as a secure sequential 
base. Then the fun of a second twin being born 58 minutes before the 
first is just a local abnormality :) That and moving the local clock to 
record a different birthday becomes a little more difficult ...

-- 
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk