Created attachment 338510 [details] C test program Description of problem: time_t/struct tm based functions fail on dates after 0x7fffffff rollover on 64bit architectures. Version-Release number of selected component (if applicable): glibc-2.5-34 How reproducible: Always Steps to Reproduce: 1. compile/run attached program 2. 3. Actual results: time_t is 8 bytes 0x7f100eff is 2037-07-21 04-14-07 +0100 0x7fffffff is 2038-01-19 03-14-07 +0000 0x80eff0ff is 1902-06-13 20-45-51 +0000 0x81dfe1ff is 1902-12-12 20-45-51 +0000 0x82cfd2ff is 1903-06-12 20-45-51 +0000 0x83bfc3ff is 1903-12-11 20-45-51 +0000 0x84afb4ff is 1904-06-10 20-45-51 +0000 Expected results: dates in 2038,2039 etc complete with requisite DST Additional info: It appears glibc in RHEL5 has been updated to cope with the extended tzdata files, but there appears to be no support for this data in either the time functions nor in the utilities (zdump,zic).
That's the expected result. (time_t)(0x7fffffff + (t * 182 *86400)) for say t = 1 is (time_t) -2131758849, which really is 1902-ish time. Didn't you mean (time_t)0x7fffffff + (t * 182 * 86400) instead?
No, the calculation is correct, as shown in the test output.
Another test to indicate the lack of handling... zdump -v Europe/London This terminates with Europe/London Sun Oct 25 00:59:59 2037 UTC = Sun Oct 25 01:59:59 2037 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 25 01:00:00 2037 UTC = Sun Oct 25 01:00:00 2037 GMT isdst=0 gmtoff=0 Europe/London 9223372036854689407 = NULL Europe/London 9223372036854775807 = NULL Whereas on F10/F11 using the same zoneinfo file this continues to the year 2499
The calculation of course isn't correct, but you also have a bug in the fprintf line. %lx format, but you cast when to (int). If you fix that up, cast to (long), then you'll see the calculation is wrong, the unfixed testcase then prints: time_t is 8 bytes 0x7f100eff is 2037-07-21 05-14-07 +0200 0x7fffffff is 2038-01-19 04-14-07 +0100 0xffffffff80eff0ff is 1902-06-13 21-45-51 +0100 0xffffffff81dfe1ff is 1902-12-12 21-45-51 +0100 0xffffffff82cfd2ff is 1903-06-12 21-45-51 +0100 0xffffffff83bfc3ff is 1903-12-11 21-45-51 +0100 0xffffffff84afb4ff is 1904-06-10 21-45-51 +0100 while fixed one: time_t is 8 bytes 0x7f100eff is 2037-07-21 05-14-07 +0200 0x7fffffff is 2038-01-19 04-14-07 +0100 0x80eff0ff is 2038-07-20 05-14-07 +0200 0x81dfe1ff is 2039-01-18 04-14-07 +0100 0x82cfd2ff is 2039-07-19 05-14-07 +0200 0x83bfc3ff is 2040-01-17 04-14-07 +0100 0x84afb4ff is 2040-07-17 05-14-07 +0200
My bad. Too long away form the coal face. But the output is still incorrect on RHEL5.3 x86_64 # rpm -q glibc tzdata glibc-2.5-34 glibc-2.5-34 tzdata-2008i-1.el5 time_t is 8 bytes 0x7f100eff is 2037-07-21 04-14-07 +0100 0x7fffffff is 2038-01-19 03-14-07 +0000 0x80eff0ff is 2038-07-20 03-14-07 +0000 0x81dfe1ff is 2039-01-18 03-14-07 +0000 0x82cfd2ff is 2039-07-19 03-14-07 +0000 0x83bfc3ff is 2040-01-17 03-14-07 +0000 0x84afb4ff is 2040-07-17 03-14-07 +0000 And the previously noted termination of zdump at 2037
That's because zic only generates the transitions from 1900 to 2037 if there is a POSIX tz string in the file. Recent glibcs (2.7 and later I think) have code to parse the embedded POSIX tz strings in the files and use it after the last transition (that's why e.g. F10 zdump shows you dates up to 2500), but RHEL5 glibc doesn't and it might be too risky to backport it. RHEL5 isn't going to be supported anywhere near 2037, worse case we could just adjust zic to generate a few years beyond 2037 by default.
Note that apps that rely on what kind of DST saving rules will be used 30 years from now are broken anyway, in some countries it is quite certain they will be wrong even next year or the year after.