| 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