Skip Menu |
 
rt.cpan.org will be shut down on March 1st, 2021.

This queue is for tickets about the TimeDate CPAN distribution.

Report information
The Basics
Id: 36211
Status: resolved
Priority: 0/
Queue: TimeDate

People
Owner: Nobody in particular
Requestors: alech [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 1.16
Fixed in: (no value)



Subject: str2time fails on dates > 2038 (time_t overflow?)
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Type: text/plain
Charset: utf8
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 279
Download (untitled) / with headers
text/plain 279b
print str2time('Dec 31 04:59:00 2040 GMT', 'UTC'); fails with the following errors: Day too big - 25932 > 24855 Sec too small - 25932 < 74752 Sec too big - 25932 > 11647 I assume this is because of a time_t overflow. Date::Parse should really be Y2038-safe ... Cheers, Alex
MIME-Version: 1.0 (Apple Message framework v753)
X-Spam-Status: No, hits=-2.6 required=8.0 tests=BAYES_00
In-Reply-To: <rt-3.6.HEAD-32600-1211901974-1305.36211-4-0 [...] rt.cpan.org>
X-Mailer: Apple Mail (2.753)
References: <RT-Ticket-36211 [...] rt.cpan.org> <rt-3.6.HEAD-32600-1211901974-1305.36211-4-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"; delsp="yes"; format="flowed"
X-RT-Original-Encoding: utf-8
Received: from x1.develooper.com (x1.develooper.com [63.251.223.170]) by diesel.bestpractical.com (Postfix) with SMTP id 6F4954D8005 for <bug-TimeDate [...] rt.cpan.org>; Tue, 27 May 2008 19:29:59 -0400 (EDT)
Received: (qmail 11598 invoked from network); 27 May 2008 23:29:58 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 27 May 2008 23:29:58 -0000
Received: from aa.67.1343.static.theplanet.com (HELO mail.goingon.net) (67.19.103.170) by 16.mx.develooper.com (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 May 2008 16:29:51 -0700
Received: from [10.50.21.2] (client-63.249.42.207.dfw.buz.net [63.249.42.207]) by mail.goingon.net (Postfix) with ESMTP id 71DE74933C for <bug-TimeDate [...] rt.cpan.org>; Tue, 27 May 2008 18:29:48 -0500 (CDT)
Delivered-To: cpan-bug+TimeDate [...] diesel.bestpractical.com
Subject: Re: [rt.cpan.org #36211] str2time fails on dates > 2038 (time_t overflow?)
Return-Path: <gbarr [...] pobox.com>
X-Spam-Check-BY: 16.mx.develooper.com
X-Original-To: bug-TimeDate [...] rt.cpan.org
Date: Tue, 27 May 2008 18:29:45 -0500
X-Spam-Level: *
Message-Id: <6316CB06-87FF-4EC4-B07E-09EE41A9B03E [...] pobox.com>
To: bug-TimeDate [...] rt.cpan.org
Content-Transfer-Encoding: 7bit
From: Graham Barr <gbarr [...] pobox.com>
RT-Message-ID: <rt-3.6.HEAD-32600-1211931009-1085.36211-0-0 [...] rt.cpan.org>
Content-Length: 449
Download (untitled) / with headers
text/plain 449b
On May 27, 2008, at 10:26 AM, Alexander Klink via RT wrote: Show quoted text
> > print str2time('Dec 31 04:59:00 2040 GMT', 'UTC'); > > fails with the following errors: > > Day too big - 25932 > 24855 > Sec too small - 25932 < 74752 > Sec too big - 25932 > 11647 > > I assume this is because of a time_t overflow.
Yes. Show quoted text
> Date::Parse should really > be Y2038-safe ...
Why ? If it does not fit your needs, then I suggest looking at the DateTime modules Graham.
MIME-Version: 1.0
In-Reply-To: <rt-3.6.HEAD-32600-1211931009-1085.36211-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Disposition: inline
Charset: utf8
References: <RT-Ticket-36211 [...] rt.cpan.org> <rt-3.6.HEAD-32600-1211901974-1305.36211-4-0 [...] rt.cpan.org> <6316CB06-87FF-4EC4-B07E-09EE41A9B03E [...] pobox.com> <rt-3.6.HEAD-32600-1211931009-1085.36211-0-0 [...] rt.cpan.org>
Message-Id: <rt-3.6.HEAD-32632-1211983304-1877.36211-0-0 [...] rt.cpan.org>
Content-Type: text/plain
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 824
Download (untitled) / with headers
text/plain 824b
Show quoted text
> > Date::Parse should really > > be Y2038-safe ...
> > Why?
Because time does not suddenly stop in the year 2038? Because people might want to deal with dates that far away? Because time_t is not magically 32 bits? Sorry, but you sound a bit like "I don't need four digit years" in 1999 ... Even if you really think that you have a valid point for some reason, Date::Parse should at least warn when using larger dates or mention it in the documentation. Show quoted text
> If it does not fit your needs, then I suggest looking at the > DateTime modules
Done, I have switched our project to DateTime::Format::DateParse, which I can recommend as an alternative to those who want to deal with dates in the future ... str2time() can be replaced by DateTime::Format::DateParse->parse_datetime($date, [$timezone])->epoch() Cheers, Alex
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Charset: utf8
Content-Type: text/plain
Message-ID: <rt-3.6.HEAD-2295-1253371113-783.36211-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 98
This is resolved with recent perls as Time::Local, which TimeDate uses, now supports dates > 2038


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.