Skip Menu |
 

This queue is for tickets about the TimeDate CPAN distribution.

Report information
The Basics
Id: 105031
Status: new
Priority: 0/
Queue: TimeDate

People
Owner: Nobody in particular
Requestors: revhippie [...] gmail.com
Cc:
AdminCc:

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



Subject: Date::Parse -- four digit years translated to the future
Date: Sat, 6 Jun 2015 21:46:51 -0500
To: bugs-TimeDate [...] rt.cpan.org
From: Jim Davis <revhippie [...] gmail.com>
Download (untitled) / with headers
text/plain 1.1k
I think bug #53413 may have been misunderstood. After str2time uses strptime to break up the incoming date, it passes the result (with $year - 1900) to Time::Local::timelocal. timelocal uses a sliding window to determine if the year should be 19xx or 20xx, completely throwing away the *known* four-digit year that we sent to str2time. For example: say "$_\t", str2time($_) for qw( 1965-12-31 1966-01-01 ); generates: 1965-12-31 3029464800 # 2065 1966-01-01 -126208800 # 1966 (This will produce different results if run a year from now -- they'll both come back in the 21st century instead of the 20th.) This might not be a bug, but it's certainly surprising behavior. The window is documented in Time::Local, but I think Date::Parse shouldn't expose end-users to that oddity. (Perhaps by adding 1900 to the strpdate output if it notices it's been passed a complete year.) (The Date::Parse documentation refers to an early limit as 1901-12-17 00:00:00 GMT, which is currently about fifty years off.) https://metacpan.org/pod/Time::Local#Year-Value-Interpretation My apologies if I appear to be beating a dead horse. -- Jim Davis -- Jim Davis


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.