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

Lester Caine lester at lsces.uk
Wed Jun 3 15:02:45 UTC 2020

On 03/06/2020 13:31, Robert Elz wrote:
> The problem there is having discarded the original data instead of retaining
> it.   Always retain the original source data.   Then by all means, when
> computing, convert timestamps from their various local values to UTC so
> they can be more easily correctly ordered (or whatever) but use those
> converted values only for transient computations.   Store the original.
> Always.

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. In fact they simply assume that ALL 
they need to store is the offset, so have no idea that in six months 
time the offset may be different. Firebird is just 'adding timezone 
datatypes' and simply ignore anything pre 1970 so have no way to store 
the initial seconds offsets even. Just go with what works for most 
people and ignore the rest? SQL standards are just a mess when it comes 
to timezone data types and simply storing some tz identifier is not the 
whole story!

I came into this 20 years ago 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. Nowadays yes it does make sense to 
store both an original time and a normalised time, along with a 
location, and a record of which version of rules was used to do the 
normalization. Add to that a flag that indicates if the UTC time is 
fixed! My point is that for a miniscule number of users a short term 
change in TZ data may affect their plans yet much of the time it is 
judged to difficult to bother about? 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 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. 
In the past I have had cases where international medical meetings have 
been disrupted over ramadan when sessions started at local time ignoring 
the fact that is was now an hour adrift from the master timetable. The 
website may have been updated at short notice, but how long do browsers 
hold 'old' copies but in most cases the 'local' staff did not even think 
about their overseas venues :(

For historic data then the gold standard is two timestamps, location 
information and the rule set version ... along with a tolerance value, 
but the published time is UTC ...

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

More information about the tz mailing list