[tz] Bad 32 bit data in 2018f

Daniel Fischer daniel.fischer at oracle.com
Tue Oct 23 18:07:56 UTC 2018


Hi,

I'm getting bad data in the 32 bit section of some of the compiled files in zoneinfo-leaps.

The affected time zones are zones that only transition before 1901, usually from LMT to some UTC offset:

	Indian/Christmas
	Indian/Cocos
	Atlantic/South_Georgia
	Pacific/Port_Moresby
	Pacific/Chuuk
	Pacific/Yap
	Pacific/Wallis
	Pacific/Funafuti
	Pacific/Palau
	Pacific/Ponape
	Pacific/Wake
	Pacific/Pohnpei
	Pacific/Truk
	Pacific/Tarawa

The files in zoneinfo-leaps contain no transitions, and only the offset used before the transition. This causes applications that only read the 32 bit section to use LMT for these zones.

The 64 bit section, and both sections in the zoneinfo version of these files, contain >=2 transitions and offsets (e.g. one real transition and one in 2038). 


For example, zdump with a break added after /old file/ in localtime.c:

$ ./zdump $PWD/TZ/usr/share/zoneinfo*/Atlantic/South_Georgia 
.../TZ/usr/share/zoneinfo/Atlantic/South_Georgia        Tue Oct 23 12:31:33 2018 -02
.../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia  Tue Oct 23 12:04:58 2018 LMT

$ ./zdump -V $PWD/TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia 
.../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia  Sat Jul  1 00:00:00 1972 UT = Fri Jun 30 21:33:52 1972 LMT isdst=0 gmtoff=-8768
.../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia  Sat Jul  1 00:00:01 1972 UT = Fri Jun 30 21:33:52 1972 LMT isdst=0 gmtoff=-8768
[..]
.../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia  Sun Jan  1 00:00:27 2017 UT = Sat Dec 31 21:33:52 2016 LMT isdst=0 gmtoff=-8768


I found that before commit 83c119f4d ("Remove Big Bang hack"), the one offset present in the leaps version was the correct one. The structural difference is older; it just didn't affect my application because the offset was the one currently in use.


The cause appears to be this sequence of events starting at zic.c /Work around QTBUG-53071/:

1) y2038_boundary-1 transition is added (== INT32_MAX)

2) leap seconds are added to all times, pushing the 2038 transition above INT32_MAX

3) affected zones again only have transition times outside the 32 bit range => timecnt32 is 0

4) because timecnt32 is 0, timei32 is also 0, and the INT32_MIN transition isn't output either

5) because of omittype[defaulttype] = false, the oldest offset is always output regardless of the above


The workaround could probably be moved to after the leap seconds are added, especially if it's supposed to apply to the 32 bit leaps files.

This will also fix this bug, because the code that determines the 32 bit limits assumes there's at least one time after 1901, and the workaround provides one. (This is why the non-leaps version is correct.)

I'm unfortunately not familiar enough with the tz database to suggest a complete fix.


Danny

-- 
Daniel Fischer
ORACLE Deutschland B.V. & Co. KG, Riesstr. 25, 80992 München - HRA MUC 95603
Komplementaer: ORACLE DE Verw.B.V., Hertogswetering 163/167, 3543 AS Utrecht
Geschaeftsfuehrer: Alexander van der Ven, Jan Schultheiss, Val Maher      NL



More information about the tz mailing list