Dave Rolsky's interpretation of what the "asia" file *says* is happening is correct, as witness output from "zdump -v Asia/Aqtau | grep 1995": Asia/Aqtau Sat Mar 25 20:59:59 1995 UTC = Sun Mar 26 01:59:59 1995 AQTT isdst=0 Asia/Aqtau Sat Mar 25 21:00:00 1995 UTC = Sun Mar 26 03:00:00 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 17:59:59 1995 UTC = Sat Sep 23 23:59:59 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 18:00:00 1995 UTC = Sat Sep 23 23:00:00 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 21:59:59 1995 UTC = Sun Sep 24 02:59:59 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 22:00:00 1995 UTC = Sun Sep 24 02:00:00 1995 AQTT isdst=0 (Recall that for each time change zic produces a "before" and "after" line; six lines above means there were three changes in 1995). I don't know *really* happened in Asia/Aqtau in 1995; if there was indeed just one change to clocks, the "1995 Sep lastSun" line needs tweaking. --ado -----Original Message----- From: Dave Rolsky [mailto:autarch@urth.org] Sent: Friday, July 18, 2003 1:34 AM To: tz@lecserver.nci.nih.gov Subject: My confusion with Asia/Aqtau I'm trying to implement a parse/code generator based on the Olson DB _text_ files (not binary). I think I've got it mostly working, but there's some strange edge cases. One of them involves Asia/Aqtau, and I'm trying to figure out if I'm _really_ understanding what the file indicates. The observances for this zone include the following: 5:00 RussiaAsia AQT%sT 1995 Sep lastSun # Aqtau Time 4:00 RussiaAsia AQT%sT The RussiaAsia rules include the following rules which apply to those observances: Rule RussiaAsia 1993 max - Mar lastSun 2:00s 1:00 S Rule RussiaAsia 1993 1995 - Sep lastSun 2:00s 0 - Rule RussiaAsia 1996 max - Oct lastSun 2:00s 0 - By my reading, this indicates the following transitions: * On Sep 24, 1995 at 00:00:00 _local_ time, the offset from UTC changes from 05:00 to 04:00. However, the DST rule is still in effect, so the total offset goes from 06:00 to 05:00. * On Sep 24, 1995 at 01:00:00 local time (2:00s == 1:00 wall when DST is in effect), the rule changes so that DST is no longer in effect, and the cumulative offset goes from 05:00 to 04:00. Is this _really_ correct? It seems awfully strange to have an observance change so close to a DST change. And if cases like these are possible, it's really going to complicate my code. But if it is correct, I do want to get it right in my code. OTOH, if it's wrong, and such things don't happen, I'd be just as happy to leave me code as is ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
On Fri, 18 Jul 2003, Olson, Arthur David (NIH/NCI) wrote:
Dave Rolsky's interpretation of what the "asia" file *says* is happening is correct, as witness output from "zdump -v Asia/Aqtau | grep 1995":
Thanks, at least I know I'm reading this correctly. Now to make my code handle this properly ...
I don't know *really* happened in Asia/Aqtau in 1995; if there was indeed just one change to clocks, the "1995 Sep lastSun" line needs tweaking.
It sure seems odd, but given that time zones are set by governments, I won't rule anything out ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
I'm using Darwin (Mac OS X 10.2.6) and I'm getting different output than you for "zdump -v Asia/Aqtau | grep 1995". Here is the output that I'm getting: Asia/Aqtau Sat Mar 25 18:59:59 1995 GMT = Sat Mar 25 23:59:59 1995 AQTT isdst=0 Asia/Aqtau Sat Mar 25 19:00:00 1995 GMT = Sun Mar 26 01:00:00 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 17:59:59 1995 GMT = Sat Sep 23 23:59:59 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 18:00:00 1995 GMT = Sat Sep 23 22:00:00 1995 AQTT isdst=0 Does this indicate that I'm using a different version of the timezone package? How can I determine what version of the timezone package is installed on my system? I hope that I'm using version 2003a. Chuck At 8:18 AM -0400 7/18/03, Olson, Arthur David (NIH/NCI) wrote:
Dave Rolsky's interpretation of what the "asia" file *says* is happening is correct, as witness output from "zdump -v Asia/Aqtau | grep 1995":
Asia/Aqtau Sat Mar 25 20:59:59 1995 UTC = Sun Mar 26 01:59:59 1995 AQTT isdst=0 Asia/Aqtau Sat Mar 25 21:00:00 1995 UTC = Sun Mar 26 03:00:00 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 17:59:59 1995 UTC = Sat Sep 23 23:59:59 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 18:00:00 1995 UTC = Sat Sep 23 23:00:00 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 21:59:59 1995 UTC = Sun Sep 24 02:59:59 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 22:00:00 1995 UTC = Sun Sep 24 02:00:00 1995 AQTT isdst=0
(Recall that for each time change zic produces a "before" and "after" line; six lines above means there were three changes in 1995).
I don't know *really* happened in Asia/Aqtau in 1995; if there was indeed just one change to clocks, the "1995 Sep lastSun" line needs tweaking.
--ado
-----Original Message----- From: Dave Rolsky [mailto:autarch@urth.org] Sent: Friday, July 18, 2003 1:34 AM To: tz@lecserver.nci.nih.gov Subject: My confusion with Asia/Aqtau
I'm trying to implement a parse/code generator based on the Olson DB _text_ files (not binary).
I think I've got it mostly working, but there's some strange edge cases. One of them involves Asia/Aqtau, and I'm trying to figure out if I'm _really_ understanding what the file indicates.
The observances for this zone include the following:
5:00 RussiaAsia AQT%sT 1995 Sep lastSun # Aqtau Time 4:00 RussiaAsia AQT%sT
The RussiaAsia rules include the following rules which apply to those observances:
Rule RussiaAsia 1993 max - Mar lastSun 2:00s 1:00 S Rule RussiaAsia 1993 1995 - Sep lastSun 2:00s 0 - Rule RussiaAsia 1996 max - Oct lastSun 2:00s 0 -
By my reading, this indicates the following transitions:
* On Sep 24, 1995 at 00:00:00 _local_ time, the offset from UTC changes from 05:00 to 04:00. However, the DST rule is still in effect, so the total offset goes from 06:00 to 05:00.
* On Sep 24, 1995 at 01:00:00 local time (2:00s == 1:00 wall when DST is in effect), the rule changes so that DST is no longer in effect, and the cumulative offset goes from 05:00 to 04:00.
Is this _really_ correct? It seems awfully strange to have an observance change so close to a DST change. And if cases like these are possible, it's really going to complicate my code. But if it is correct, I do want to get it right in my code.
OTOH, if it's wrong, and such things don't happen, I'd be just as happy to leave me code as is ;)
-dave
/*======================= House Absolute Consulting www.houseabsolute.com =======================*/
Chuck Soper <chucks@lmi.net> writes:
Does this indicate that I'm using a different version of the timezone package?
Most likely, yes.
How can I determine what version of the timezone package is installed on my system? I hope that I'm using version 2003a.
There should be a way to do this, at least for the timezone code like zdump.c. Perhaps you could add a "--version" option for zdump and zic? If you donated code to do that, I suspect that Arthur David Olson would buy it. zdump has this at the start: #ifndef lint #ifndef NOID static char elsieid[] = "@(#)zdump.c 7.29"; #endif /* !defined NOID */ #endif /* !defined lint */ and zic.c has something similar, but they don't work well. Nowadays many compilers optimize away these unused strings. Basicall, all the "--version" option needs to do is to print the elsieid.
Date: Mon, 21 Jul 2003 22:42:46 -0700 From: Paul Eggert <eggert@twinsun.com> Message-ID: <7wel0ji0bt.fsf@sic.twinsun.com> | Chuck Soper <chucks@lmi.net> writes: | > How can I determine what version of the timezone package is installed | > on my system? I hope that I'm using version 2003a. | | There should be a way to do this, at least for the timezone code like | zdump.c. Perhaps you could add a "--version" option for zdump and | zic? I suspect that the query was more concerned with which version of the database is installed (what sources the compiled zoneinfo files came from), rather than which versions of the tools, which, while interesting, isn't likely to be of much concern to most people (as long as they work, who cares, if they don't work, replace them with the latest version, try again, if that fixed it, who cares what version was there previously, if it didn't, time for e-mail to the list...) kre
Paul Eggert wrote:
Chuck Soper <chucks@lmi.net> writes:
Does this indicate that I'm using a different version of the timezone package?
Most likely, yes.
How can I determine what version of the timezone package is installed on my system? I hope that I'm using version 2003a.
There should be a way to do this, at least for the timezone code like zdump.c. Perhaps you could add a "--version" option for zdump and zic? If you donated code to do that, I suspect that Arthur David Olson would buy it.
zdump has this at the start:
#ifndef lint #ifndef NOID static char elsieid[] = "@(#)zdump.c 7.29"; #endif /* !defined NOID */ #endif /* !defined lint */
and zic.c has something similar, but they don't work well. Nowadays many compilers optimize away these unused strings.
Basicall, all the "--version" option needs to do is to print the elsieid.
I think the --version is a good idea but just showing the file version does not give enough information. the statement "I hope that I'm using version 2003a." indicates that we also need to include the tz version where the change was added. there are also times where the update does not have any code changes - just data changes. it does not seem to be possible to tell what version of the data is actually being used. there may be many cases where only the final data is available but none of the rule data files. there is reserved data in the header of each file (16 bytes) - would this be a good location to put this kind of information? -- Martin Smoot Network Storage Solutions 703-834-2242 msmoot@nssolutions.com www.nssolutions.com
At 10:42 PM -0700 7/21/03, Paul Eggert wrote:
Chuck Soper <chucks@lmi.net> writes:
Does this indicate that I'm using a different version of the timezone package?
Most likely, yes.
I would like to be able to verify what version of the timezone package (data and tools) is installed on my operating system. If I had evidence that an old version of the timezone package was being used in a current operating system then I could file a problem report with the OS vendor. This mechanism could facilitate OS vendors to stay current with the time zone package (I don't know if this is an issue). I think that adding version information to each time zone information file might be a way to verify version information for these data. In a previous post, Martin Smoot suggested that the sixteen bytes reserved for future use in the header might be used for version information. Would both a package version and a file version be needed?
How can I determine what version of the timezone package is installed on my system? I hope that I'm using version 2003a.
There should be a way to do this, at least for the timezone code like zdump.c. Perhaps you could add a "--version" option for zdump and zic? If you donated code to do that, I suspect that Arthur David Olson would buy it.
zdump has this at the start:
#ifndef lint #ifndef NOID static char elsieid[] = "@(#)zdump.c 7.29"; #endif /* !defined NOID */ #endif /* !defined lint */
and zic.c has something similar, but they don't work well. Nowadays many compilers optimize away these unused strings.
Basicall, all the "--version" option needs to do is to print the elsieid.
A "--version" option for zdump would also be useful.
"Olson, Arthur David (NIH/NCI)" <olsona@dc37a.nci.nih.gov> writes:
I don't know *really* happened in Asia/Aqtau in 1995;
Nor do I, alas.
if there was indeed just one change to clocks, the "1995 Sep lastSun" line needs tweaking.
Since I invented the 1995 transition in the tz data, I suppose I should be the one to clean it up.... We don't know when in the year the transition occurred. I'm not even 100% sure the transition exists; it's derived only from the IATA data, which are fallible. But, on further thought, it would have made far more sense to make the change in spring than in fall. So I'm inclined to make the following fix, which I'll incorporate in my next proposed patch. @@ -926,7 +901,7 @@ Zone Asia/Aqtau 3:21:04 - LMT 1924 May 6:00 - SHET 1982 Apr 1 5:00 RussiaAsia SHE%sT 1991 5:00 - SHET 1991 Dec 16 # independence - 5:00 RussiaAsia AQT%sT 1995 Sep lastSun # Aqtau Time + 5:00 RussiaAsia AQT%sT 1995 Mar lastSun 2:00 # Aqtau Time 4:00 RussiaAsia AQT%sT # West Kazakhstan Zone Asia/Oral 3:25:24 - LMT 1924 May 2 # or Ural'sk PS to Dave Rolsky: Thanks for reporting the bug.
participants (6)
-
Chuck Soper -
Dave Rolsky -
Martin Smoot -
Olson, Arthur David (NIH/NCI) -
Paul Eggert -
Robert Elz