Description of problem: Version-Release number of selected component (if applicable): How reproducible: run perl -MTime::Local -e 'timegm(0, 0, 0, 01, 01, 2038)' Steps to Reproduce: 1. run perl -MTime::Local -e 'timegm(0, 0, 0, 01, 01, 2038)' Actual results: Day too big - 24868 > 24855 Sec too small - 24868 < 74752 Sec too big - 24868 > 11647 Cannot handle date (0, 0, 0, 1, 1, 2038) at -e line 1. Expected results: no warnings/errors printed Additional info: Reproducible on 64 bit machines. Also does not work for dates < ~ 1902 Bug in perl core module Time::Local, I think it's fixed in 1.19 I'd suggest to backport a fix, it's something related to wrong type for Integers.
Full support for times after year 2038 has been introduced in perl 5.12 while distribution provides perl 5.8.8.
Yes, there is notice in 5.12 delta: http://search.cpan.org/~jesse/perl-5.12.0/pod/perl5120delta.pod#Y2038_compliance about Y2038 However I am not sure what that means, what exactly was not working prior to that fix? (maybe it was time() function which does not afect users until Y2038). The problem I described is fixed in 5.8.9 (i.e. Time::Local 1.19). 5.8.9 is latest stable release of 5.8.x branch. Also this problem can afferct users right now, before Y2038.
UPD: It seems on 64bit machines problem fixed in 5.8.9 (Time::Local 1.19). On 32bit machines problem indeed fixed with 5.12.0 (I tested original perl tarballs) (even if compiled with 64bit ints support) So, you were right, and I am not sure now if it's worth fixing.
also, 32bit linux, in general don't seem to support Y2038 in file system date/time functions and maybe other API call. so support for 32bit perls makes less sense anyway.
Definitely. 5.12.0 solved the problem by adding private localtime implementations and the change is too invasive and it changes ABI, so I cannot back-port the perl changes to support 32-bit platforms. However Time::Local fix to add support on 64-bit platforms is easy and without any significant problems (only it does not croak on too big year, but that's problem even with latest perl). The fix seems correct as the time_t size correspond with ivsize used in the fix: platform time_t intsize ivsize ------------------------------------------ ppc 4 4 4 s390 4 4 4 x86_64 8 4 8 ppc64 8 4 8 s390x 8 4 8 i386 4 4 4 ia64 8 4 8 I also verified the patch does not break things on i386 and fixes the issue in x86_64.
Created attachment 854867 [details] Fix ported from Time-Local-1.19
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
How to test: (1) Run: $ perl -MTime::Local -e 'print timegm(0, 0, 0, 01, 01, 2038), qq{\n}' Before: It will die with various errors as mentioned in the comment #1. After: It will print number 2148595200. Make sure you check for this value (number of seconds since the epoch beginning). Please note that it will still fail on 32-bit systems. This is expected.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1198.html
This patch caused a regression in using Time::Locale::timelocale(). See bug #1149375.
DST on dates after 2038 is not processed correctly, likely to be a glibc bug 1155140.
Yes. That's because perl-5.8.8 relies on glibc.