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 =======================*/