Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the TimeDate CPAN distribution.

Report information
The Basics
Id:
105031
Status:
open
Priority:
Low/Low
Queue:

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

BugTracker
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>
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 runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

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