More strangenes in zdump: no LMT
The data for Africa/Abidjan contains this: Zone Africa/Abidjan -0:16:08 - LMT 1912 0:00 - GMT But zdump gives me this: Africa/Abidjan Mon Jan 1 00:16:07 1912 UTC = Sun Dec 31 23:59:59 1911 GMT isdst=0 gmtoff=-968 Africa/Abidjan Mon Jan 1 00:16:08 1912 UTC = Mon Jan 1 00:16:08 1912 GMT isdst=0 gmtoff=0 Africa/Abidjan Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 03:14:07 2038 GMT isdst=0 gmtoff=0 Africa/Abidjan Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 03:14:07 2038 GMT isdst=0 gmtoff=0 The version of the time zone data installed on my system (GNU/Linux Debian unstable) may not match the version of the files I'm looking at (2003a) but I didn't think that the LMT name was something terribly recent. If look directly at the binary data for this zone on my system, I see that it does indeed contain the string "LMT". Any idea where this is getting munged? I'm trying to generate tests for my code based on the output of zdump, but I'm getting weird failures because of this problem. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
On Sat, 19 Jul 2003, Dave Rolsky wrote:
The data for Africa/Abidjan contains this:
Zone Africa/Abidjan -0:16:08 - LMT 1912 0:00 - GMT
But zdump gives me this:
Africa/Abidjan Mon Jan 1 00:16:07 1912 UTC = Sun Dec 31 23:59:59 1911 GMT isdst=0 gmtoff=-968 Africa/Abidjan Mon Jan 1 00:16:08 1912 UTC = Mon Jan 1 00:16:08 1912 GMT isdst=0 gmtoff=0 Africa/Abidjan Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 03:14:07 2038 GMT isdst=0 gmtoff=0 Africa/Abidjan Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 03:14:07 2038 GMT isdst=0 gmtoff=0
This appears to happen with _many_ time zones. zdump is telling me that the short name for the zone is whatever happens to be the most recent name, and ignoring historical names. For example, with Pacific/Pago_Pago, I get: Pacific/Pago_Pago Sun Jan 1 11:22:47 1911 UTC = Sat Dec 31 23:59:59 1910 SST isdst=0 gmtoff=-40968 Pacific/Pago_Pago Sun Jan 1 11:22:48 1911 UTC = Sat Dec 31 23:52:48 1910 SST isdst=0 gmtoff=-41400 Pacific/Pago_Pago Sun Jan 1 11:29:59 1950 UTC = Sat Dec 31 23:59:59 1949 SST isdst=0 gmtoff=-41400 Pacific/Pago_Pago Sun Jan 1 11:30:00 1950 UTC = Sun Jan 1 00:30:00 1950 SST isdst=0 gmtoff=-39600 Just to increase the pain, note that it's completely ignoring the April, 1967 and Nov 30, 1983 observance changes. I assume it's doing this because these _only_ changed the short name, not the offset. In fact, from what I can tell, _any_ time there is an observance change which _only_ changes the short name, the change itself is ignored. For example, the 'war time' and 'peace time' changes in the US during WWII are entirely skipped. Looking at the binary zoneinfo files, I do see the strings for these short names, like "EWT" and "EPT" for America/New_York. So the question is where is the bug being introduced? - zic - libc - zdump I'm guessing that it's one of the first two, since zdump is just spitting out what libc gives it, and libc only knows what the zoneinfo files say. Could this be happening in the writezone() function in zic.c, where the comment says "Optimize"? I'm not much of a C programmer, so following the zic code makes my brane hurt quite a bit. It looks like it _could_ be happening there. If so, I'd consider this a bug, since it's losing information. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
Dave Rolsky <autarch@urth.org> writes:
Could this be happening in the writezone() function in zic.c, where the comment says "Optimize"?
No, I think it's a glibc bug. When I build tzcode on Solaris 8, and use it to run both 'zic' and 'zdump', I get the following output: $ ./zdump -v Africa/Abidjan Africa/Abidjan Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:29:44 1901 LMT isdst=0 Africa/Abidjan Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:29:44 1901 LMT isdst=0 Africa/Abidjan Mon Jan 1 00:16:07 1912 UTC = Sun Dec 31 23:59:59 1911 LMT isdst=0 Africa/Abidjan Mon Jan 1 00:16:08 1912 UTC = Mon Jan 1 00:16:08 1912 GMT isdst=0 Africa/Abidjan Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 03:14:07 2038 GMT isdst=0 Africa/Abidjan Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 03:14:07 2038 GMT isdst=0 so it doesn't have the problems that you mentioned.
participants (2)
-
Dave Rolsky -
Paul Eggert