On 31/07/2020 00:51, Paul.Koning@dell.com wrote:
On Jul 30, 2020, at 6:41 PM, Robert Elz<kre@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