Hello, A group of developers including myself has been charged with dealing with time zones in our database. We have been looking into using the IANA TZ Database as our source. In order to create utilities to get historical data correctly, and to future proof our code as much as possible, there were a couple of questions we have been trying to find the answers to. * If an entity breaks off from a current time zone, does the data base fork the current time zone(A) and add a new time zone(B) with time zone B having all the historical data of A? * In the INANA time zone database, the file "europe" contains information for Time Zone Europe/Dublin. There are three lines that are proceeded with the comment "# These three lines are for when SAVE values are always nonnegative." These lines are also preceded by comment Delimiter (Please see below). Since the data follows the Comment Delimiter it is ignored on load. Is database supposed to load this information? What is the purpose of these comments? # These three lines are for when SAVE values are always nonnegative. # 1:00 - IST 1971 Oct 31 2:00u # 0:00 GB-Eire GMT/IST 1996 # 0:00 EU GMT/IST
On 4/1/20 8:30 AM, Dustin J. Dirth via tz wrote:
* If an entity breaks off from a current time zone, does the data base fork the current time zone(A) and add a new time zone(B) with time zone B having all the historical data of A?
Yes. For the most recent example of this, see the introduction of Asia/Qostanay (by a split from Asia/Qyzylorda) in: https://github.com/eggert/tz/commit/6fb0daf8a1906e47a96a5f035d723468fe996461
* In the INANA time zone database, the file "europe" contains information for Time Zone Europe/Dublin.
There are three lines that are proceeded with the comment "# These three lines are for when SAVE values are always nonnegative."
These lines are also preceded by comment Delimiter (Please see below).
Since the data follows the Comment Delimiter it is ignored on load. Is database supposed to load this information?
What is the purpose of these comments?
They're for converting to rearguard format, used by software that cannot handle negative DST. See the 'ziguard.awk' file and the Makefile rule for rearguard.zi. POSIX and tzcode have supported negative DST for decades, but some apps (notably Java-based) reportedly go belly-up with it so we have an out for them.
Envoyé de mon iPad
Le 1 avr. 2020 à 14:23, Paul Eggert <eggert@cs.ucla.edu> a écrit :
On 4/1/20 8:30 AM, Dustin J. Dirth via tz wrote:
* If an entity breaks off from a current time zone, does the data base fork the current time zone(A) and add a new time zone(B) with time zone B having all the historical data of A?
Yes. For the most recent example of this, see the introduction of Asia/Qostanay (by a split from Asia/Qyzylorda) in:
https://github.com/eggert/tz/commit/6fb0daf8a1906e47a96a5f035d723468fe996461
Keeping in mind that A will always be the area containing the named city. So, for example, if New York changes time zone, it keeps America/New_York and the rest of the zone becomes America/Philadelphia. (A question: Is it the legal city or the metro area whose size is measured? This matters if IL or CO shifts: the remaining largest cities proper are Houston and Albuquerque, but the largest metros are Dallas and Salt Lake City.)
On 01/04/2020 16:30, Dustin J. Dirth via tz wrote:
In the INANA time zone database, the file "europe" contains information for Time Zone Europe/Dublin.
It should also be noted that for historic records, the UK/Ireland area is only valid for timezone data post 1970. The pre-1970 time frame will only be correct if the 'backzone' data is included to correct differences in the various islands in the area. Using those timezones may only return the London data without any warning. Other areas of the world have similar problems but there is the potential that the pre-1970 data has not be validated. There is not currently any service that can be used to provide accurate pre-1970 due to there currently being gaps in the historic data. -- 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
participants (5)
-
Dustin J. Dirth -
J Andrew Lipscomb -
J William Piggott -
Lester Caine -
Paul Eggert