FW: Question about Leap Second Features
Dan White is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Dan White [mailto:ygor@comcast.net] Sent: Saturday, February 18, 2006 9:59 AM To: tz@lecserver.nci.nih.gov Subject: Question about Leap Second Features Is there any implementation for this information on Microsoft operating systems ?
Any Microsoft operating system that is accurate down to the second can probably be hand-picked from Bill Gates' garage ... ;-) Jesper -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: Monday, February 20, 2006 08:41 To: tz@lecserver.nci.nih.gov Subject: FW: Question about Leap Second Features Dan White is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Dan White [mailto:ygor@comcast.net] Sent: Saturday, February 18, 2006 9:59 AM To: tz@lecserver.nci.nih.gov Subject: Question about Leap Second Features Is there any implementation for this information on Microsoft operating systems ?
From tz database version 2005l to current version (2006a) the timezone Indian/Yap was removed. It was present in versions 2005k and previous. I wonder if that was a deliberate decision, and if so, why? I haven't seen any information about it in the email list.
Jesper Nørgaard Welen -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: Monday, February 20, 2006 08:41 To: tz@lecserver.nci.nih.gov Subject: FW: Question about Leap Second Features Dan White is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Dan White [mailto:ygor@comcast.net] Sent: Saturday, February 18, 2006 9:59 AM To: tz@lecserver.nci.nih.gov Subject: Question about Leap Second Features Is there any implementation for this information on Microsoft operating systems ?
Jesper Norgaard Welen <jnorgard@prodigy.net.mx> writes:
From tz database version 2005l to current version (2006a) the timezone Indian/Yap was removed.
I assume you mean "Pacific/Yap"? I don't see any record of any "Indian/Yap". In 2005l Pacific/Yap was moved to the 'backward' file. This was suggested by Mark Davis, who noted that it was a duplicate entry with Pacific/Truk (as it had the same time zone history since 1970). This was noted in my 2005-08-17 proposed tz changes. I also CC'ed more-detailed email about this to <tz@lecserver.nci.nih.gov> but perhaps it got lost due to the fact that I should have used <tz@elsie.nci.nih.gov>. I enclose another copy of the earlier message below. Note that some of the discussion is obsolete new (e.g., the stuff about EST5EDT was fixed in a different way, in December). From: Paul Eggert <eggert@cs.ucla.edu> Date: Tue, 16 Aug 2005 11:12:45 -0700 To: "Mark Davis" <mark.davis@icu-project.org> Cc: <tz@lecserver.nci.nih.gov> Subject: Re: Request from CLDR committee
From: "Mark Davis" <mark.davis@icu-project.org> Sent: Tuesday, August 09, 2005 07:28
1. Missing Country Codes. ... Suggested changes: To antarctica, add Zone Atlantic/Bouvet 0:00 - GMT Zone Pacific/Heard 5:00 - GMT
The problem with this approach, as I see it, is that the data are purely invented. Heard Island is not 5 hours ahead of GMT, since nobody lives there. In a practical sense, local time is undefined for uninhabited locations, and it would be misleading for the tz database to imply otherwise. I suppose we could work around this by using a "zzz" entry, e.g.: Zone Indian/Heard 0:00 - zzz but I wonder whether this might cause more troubles than it'd cure. "zzz" currently is used to denote local time for locations that are sometimes inhabited and sometimes uninhabited. However, this is a hack: what is really wanted is a relation where the entries for local time are simply absent while the location is uninhabited. As far as I can tell, the country codes HM and BV are ISO 3166 curiosities. For example, www.bv is now owned by Black & Veatch, a privately-held firm that two of my cousins work for -- it has nothing to do with Bouvet Island. I wouldn't worry too much about these glitches in the ISO database.
2. Enabling Canonical IDs
One dependency we have is that the last field in the canonical ID be unique. That is, we can't have both a Europe/London and an America/London.
I wouldn't rely on this. It's too constraining on the database. Part of the point of having a tree-structured name space is the desire to avoid constraints like these.
This appears to be the practice in the TZ database, as evidenced by the following in southamerica:
# Bahia (BA) # There are too many Salvadors elsewhere, so use America/Bahia instead # of America/Salvador.
That comment refers to the other Salvadors in America. If there were a Salvador in Africa (or even in America/Argentina) it wouldn't be a problem.
We also depend on the feature that every equivalence class (except Etc/...) has exactly one member in zone.tab.
That sounds reasonable. How about if we add something to Theory saying that zone.tab "is intended to be an exhaustive list of canonical names for geographic regions."
List A. TZIDs that are not linked, but are the same
001 Etc/GMT 001 Etc/UTC 001 Etc/UCT -- not linked, identical
They are not identical, since they use different abbreviations. Hence they cannot be linked. For example, on my Debian GNU/Linux 3.1 box: $ TZ=Etc/GMT date Tue Aug 16 17:31:23 GMT 2005 $ TZ=Etc/UTC date Tue Aug 16 17:31:27 UTC 2005 The difference in output is intentional. How about if you simplify your life by simply ignoring the Etc/* names?
List B. TZIDs that are not linked, are different locations, but are the same since 1970
AQ Antarctica/Mawson AQ Antarctica/Vostok -- same since 57
As far as I know it's merely a coincidence that the two bases use the same time zone. Most crucially the bases belong to different countries (so to some extent the "different country" rule applies, though admittedly Antarctica is special) and use different supply lines. I'd rather leave them alone for now.
FM Pacific/Truk FM Pacific/Yap -- same since 70 GB Europe/Belfast GB Europe/London -- same since 68 ML Africa/Bamako ML Africa/Timbuktu -- same since 60
OK, let's merge those. It is more consistent to do so. We'll keep backward-compatibility entries, of course. Sigh. I sort of liked having Timbuktu in the database.
List C. TZIDs that are linked, but refer to different locations.
As a rule, these locations have identical time zone histories except before the advent of standard time; and LMT (by definition) is approximate, so I don't see the harm in keeping them linked. If they are trouble for your system, perhaps you can keep a list of exceptions and filter them out. That being said, perhaps some of the "Link" lines should be moved from northamerica (etc.) to backward. For example, the line Link America/New_York EST5EDT is in the "northamerica" file, but it's really there only for backward compatibility with System V, so perhaps we should move it to "backward". Arthur, would you be open to that sort of thing?
I'd request that when any IDs are removed from zone.tab, that the reasons be annotated in one of the data files. As far as I can tell, the reason is only in email: Subject: Re: proposed tz changes for US, Indiana, Australia, Tunisia, Nunavut, etc. Organizational changes * Remove the following Zone entries since they are identical to other Zone entries since 1970. For backward compatibility, add links in the "backward" file so that the names still work. Africa/Timbuktu Europe/Belfast Pacific/Yap ... * In Argentina, the America/Argentina/ComodRivadavia zone was wrong: Chubut actually used the same transitions as Catamarca. Fixing this removed the need for America/Argentina/ComodRivadavia (though it is retained in the "backward" file). .... Paul Eggert wrote:
Jesper Norgaard Welen <jnorgard@prodigy.net.mx> writes:
From tz database version 2005l to current version (2006a) the timezone Indian/Yap was removed.
I assume you mean "Pacific/Yap"? I don't see any record of any "Indian/Yap".
In 2005l Pacific/Yap was moved to the 'backward' file. This was suggested by Mark Davis, who noted that it was a duplicate entry with Pacific/Truk (as it had the same time zone history since 1970).
This was noted in my 2005-08-17 proposed tz changes. I also CC'ed more-detailed email about this to <tz@lecserver.nci.nih.gov> but perhaps it got lost due to the fact that I should have used <tz@elsie.nci.nih.gov>. I enclose another copy of the earlier message below. Note that some of the discussion is obsolete new (e.g., the stuff about EST5EDT was fixed in a different way, in December).
From: Paul Eggert <eggert@cs.ucla.edu> Date: Tue, 16 Aug 2005 11:12:45 -0700 To: "Mark Davis" <mark.davis@icu-project.org> Cc: <tz@lecserver.nci.nih.gov> Subject: Re: Request from CLDR committee
From: "Mark Davis" <mark.davis@icu-project.org> Sent: Tuesday, August 09, 2005 07:28
1. Missing Country Codes. ... Suggested changes: To antarctica, add Zone Atlantic/Bouvet 0:00 - GMT Zone Pacific/Heard 5:00 - GMT
The problem with this approach, as I see it, is that the data are purely invented. Heard Island is not 5 hours ahead of GMT, since nobody lives there. In a practical sense, local time is undefined for uninhabited locations, and it would be misleading for the tz database to imply otherwise.
I suppose we could work around this by using a "zzz" entry, e.g.:
Zone Indian/Heard 0:00 - zzz
but I wonder whether this might cause more troubles than it'd cure. "zzz" currently is used to denote local time for locations that are sometimes inhabited and sometimes uninhabited. However, this is a hack: what is really wanted is a relation where the entries for local time are simply absent while the location is uninhabited.
As far as I can tell, the country codes HM and BV are ISO 3166 curiosities. For example, www.bv is now owned by Black & Veatch, a privately-held firm that two of my cousins work for -- it has nothing to do with Bouvet Island. I wouldn't worry too much about these glitches in the ISO database.
2. Enabling Canonical IDs
One dependency we have is that the last field in the canonical ID be unique. That is, we can't have both a Europe/London and an America/London.
I wouldn't rely on this. It's too constraining on the database. Part of the point of having a tree-structured name space is the desire to avoid constraints like these.
This appears to be the practice in the TZ database, as evidenced by the following in southamerica:
# Bahia (BA) # There are too many Salvadors elsewhere, so use America/Bahia instead # of America/Salvador.
That comment refers to the other Salvadors in America. If there were a Salvador in Africa (or even in America/Argentina) it wouldn't be a problem.
We also depend on the feature that every equivalence class (except Etc/...) has exactly one member in zone.tab.
That sounds reasonable. How about if we add something to Theory saying that zone.tab "is intended to be an exhaustive list of canonical names for geographic regions."
List A. TZIDs that are not linked, but are the same
001 Etc/GMT 001 Etc/UTC 001 Etc/UCT -- not linked, identical
They are not identical, since they use different abbreviations. Hence they cannot be linked. For example, on my Debian GNU/Linux 3.1 box:
$ TZ=Etc/GMT date Tue Aug 16 17:31:23 GMT 2005 $ TZ=Etc/UTC date Tue Aug 16 17:31:27 UTC 2005
The difference in output is intentional.
How about if you simplify your life by simply ignoring the Etc/* names?
List B. TZIDs that are not linked, are different locations, but are the same since 1970
AQ Antarctica/Mawson AQ Antarctica/Vostok -- same since 57
As far as I know it's merely a coincidence that the two bases use the same time zone. Most crucially the bases belong to different countries (so to some extent the "different country" rule applies, though admittedly Antarctica is special) and use different supply lines. I'd rather leave them alone for now.
FM Pacific/Truk FM Pacific/Yap -- same since 70 GB Europe/Belfast GB Europe/London -- same since 68 ML Africa/Bamako ML Africa/Timbuktu -- same since 60
OK, let's merge those. It is more consistent to do so. We'll keep backward-compatibility entries, of course. Sigh. I sort of liked having Timbuktu in the database.
List C. TZIDs that are linked, but refer to different locations.
As a rule, these locations have identical time zone histories except before the advent of standard time; and LMT (by definition) is approximate, so I don't see the harm in keeping them linked. If they are trouble for your system, perhaps you can keep a list of exceptions and filter them out.
That being said, perhaps some of the "Link" lines should be moved from northamerica (etc.) to backward. For example, the line
Link America/New_York EST5EDT
is in the "northamerica" file, but it's really there only for backward compatibility with System V, so perhaps we should move it to "backward". Arthur, would you be open to that sort of thing?
Mark Davis <mark.davis@icu-project.org> writes:
I'd request that when any IDs are removed from zone.tab, that the reasons be annotated in one of the data files.
That's been on my list of things to do for about five years now. All it would take is for someone to go through tzarchive and generate a ChangeLog file from it. Volunteers would be welcome.
While that would be useful, for now I'd suggest at least documenting the reasons for changes going forward. Mark (Our main concern is with IDs in zone.tab that get removed, renamed, or deleted since 2003, since then we have to compensate for such changes.) Paul Eggert wrote:
Mark Davis <mark.davis@icu-project.org> writes:
I'd request that when any IDs are removed from zone.tab, that the reasons be annotated in one of the data files.
That's been on my list of things to do for about five years now. All it would take is for someone to go through tzarchive and generate a ChangeLog file from it. Volunteers would be welcome.
participants (4)
-
Jesper Norgaard Welen -
Mark Davis -
Olson, Arthur David (NIH/NCI) [E] -
Paul Eggert