tz behavior difference TZif vs. TZif2
I still see a behavior difference for some timezones with 32-bit 2005l localtime() when using TZif vs. TZif2 (built with 2006b zic.c) format timezones. Do you get this behavior too? I would have expected the difference to show up on a zgress test, however. It seems the TZif2 file has an extra "LMT" in the first portion of the binary, which is supposed to be identical to the old TZif files. The extra "LMT" also seems to cause Solaris localtime() to behave differently. It would be better for Solaris compatibility if "LMT" was not included in the first portion of the TZif2 file, and if the first portion of a TZif2 file was identical to a TZif file except for the "2" in "TZif2". As an example using 32-bit 2005l localtime.c, this is the behavior difference of zdump for Indian/Cocos timezone between TZif format vs. TZif2 format: old TZif vs. new TZif2 Indian/Cocos: < Indian/Cocos Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 03:15:52 1901 CCT isds t=0 < Indian/Cocos Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 03:15:52 1901 CCT isds t=0 < Indian/Cocos Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 09:44:07 2038 CCT isds t=0 < Indian/Cocos Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 09:44:07 2038 CCT isds t=0 ---
Indian/Cocos Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 03:13:32 1901 LMT isds t=0 Indian/Cocos Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 03:13:32 1901 LMT isds t=0 Indian/Cocos Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 09:41:47 2038 LMT isds t=0 Indian/Cocos Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 09:41:47 2038 LMT isds
This is a dump of the Indian/Cocos TZif2 file: % od -xc ./Indian/Cocos 0000000 545a 6966 3200 0000 0000 0000 0000 0000 T Z i f 2 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 0000 0000 0000 0001 0000 0001 0000 0000 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 \0 0000040 0000 0000 0000 0001 0000 0008 0000 5adc \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 \b \0 \0 Z 334 0000060 0000 4c4d 5400 4343 5400 0000 545a 6966 \0 \0 L M T \0 C C T \0 \0 \0 T Z i f 0000100 3200 0000 0000 0000 0000 0000 0000 0000 2 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000120 0000 0002 0000 0002 0000 0000 0000 0001 \0 \0 \0 002 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 001 0000140 0000 0002 0000 0008 ffff ffff 7c55 26a4 \0 \0 \0 002 \0 \0 \0 \b 377 377 377 377 | U & 244 0000160 0100 005a dc00 0000 005b 6800 044c 4d54 001 \0 \0 Z 334 \0 \0 \0 \0 [ h \0 004 L M T 0000200 0043 4354 0000 0000 000a 4343 542d 363a \0 C C T \0 \0 \0 \0 \0 \n C C T - 6 : 0000220 3330 0a00 3 0 \n 0000223 This is a dump of the Indian/Cocos TZif file: % od -xc /usr/share/lib/zoneinfo/Indian/Cocos 0000000 545a 6966 0000 0000 0000 0000 0000 0000 T Z i f \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 0000 0000 0000 0001 0000 0001 0000 0000 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 \0 0000040 0000 0000 0000 0001 0000 0004 0000 5b68 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 004 \0 \0 [ h 0000060 0000 4343 5400 0000 \0 \0 C C T \0 \0 \0 0000070 The following timezones (which seem to have no transitions) showed similar behavior differences with 2005l localtime.c and TZif vs. TZif2 formats: Africa/Bujumbura Africa/Kinshasa Africa/Lome Africa/Lubumbashi Atlantic/South_Georgia Indian/Christmas Indian/Cocos Pacific/Fakaofo Pacific/Funafuti Pacific/Palau Pacific/Ponape Pacific/Port_Moresby Pacific/Tarawa Pacific/Truk Pacific/Wake Pacific/Wallis
Robbin Kawabata <Robbin.Kawabata@eng.sun.com> writes:
old TZif vs. new TZif2 Indian/Cocos:
< Indian/Cocos Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 03:15:52 1901 CCT isdst=0 ...
Indian/Cocos Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 03:13:32 1901 LMT isdst=0
This appears to be a bug in the TZif2 zic. The time stamp in question should be CCT, not LMT, as Indian/Cocos switched from LMT to CCT in 1900. Looking at the other troublesome entries, they all seem to have the property that their last transition preceded the time stamp that is 2**31 seconds before the epoch (namely, Fri Dec 13 20:45:52 1901 UTC). Most likely the new zic is mishandling this case.
participants (2)
-
Paul Eggert -
Robbin Kawabata