Bug 1057047
Summary: | perl Time::Local does not work with dates after 2038 or below 1902 | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Victor Efimov <victor> | ||||
Component: | perl | Assignee: | perl-maint-list | ||||
Status: | CLOSED ERRATA | QA Contact: | Lukáš Zachar <lzachar> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 5.11 | CC: | ppisar, psabata | ||||
Target Milestone: | rc | Keywords: | Patch | ||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | perl-5.8.8-42.el5 | Doc Type: | Bug Fix | ||||
Doc Text: |
Cause:
Using timegm() Perl function to convert calendar time
beyond year 2038 into number of seconds elapsed from the
UNIX epoch beginning on 64-bit platform.
Consequence:
timegm() function refuses to convert such date and an
error message gets printed.
Fix:
An upstream fix has been applied to detect 64-bit perl
correctly.
Result:
It's possible to convert dates beyond year 2038 with
Perl's timegm() function on 64-bit platforms. 32-bit
platforms will still refuse such requests as system
time_t type is not large enough on 32-bit platforms.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2014-09-16 00:32:14 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Victor Efimov
2014-01-23 12:07:19 UTC
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. |