|
|
Bug 22639 reports localtime failing to handle time offset transitions
correctly in 2039 and later on platforms with 64-bit time_t.
The problem is the use of SECSPERDAY (constant 86400) in calculations
such as
t = ((year - 1970) * 365
+ /* Compute the number of leapdays between 1970 and YEAR
(exclusive). There is a leapday every 4th year ... */
+ ((year - 1) / 4 - 1970 / 4)
/* ... except every 100th year ... */
- ((year - 1) / 100 - 1970 / 100)
/* ... but still every 400th year. */
+ ((year - 1) / 400 - 1970 / 400)) * SECSPERDAY;
where t is of type time_t and year is of type int. Before my commit
92bd70fb85bce57ac47ba5d8af008736832c955a (an update from tzcode,
included in 2.26 and later releases), SECSPERDAY was obtained from a
file imported from tzcode, where the value included a cast to
int_fast32_t. On 64-bit platforms, glibc defines int_fast32_t to be
long int, so 64-bit, but my patch resulted in it changing to int.
(The bug would probably have existed even before my patch for x32,
which has 64-bit time_t but 32-bit int_fast32_t, but I haven't
verified that.)
This patch fixes the problem by including a cast to time_t in the
definition of SECSPERDAY. (64-bit time support for 32-bit systems
should move such code that isn't a public interface to using the
internal 64-bit version of time_t throughout.)
Tested for x86_64 and x86.
[BZ #22639]
* time/tzset.c (SECSPERDAY): Cast to time_t.
* time/tst-y2039.c: New file.
* time/Makefile (tests): Add tst-y2039.
|
