Closed jimav closed 6 years ago
autarch
commented
6 years ago If this is a Date::Parse bug I'm a little confused as to why you've reported it here. This is the Time-Local distribution's issue tracker. See https://rt.cpan.org/Dist/Display.html?Name=TimeDate for the TimeDate distribution's bug tracker.
jimav
commented
6 years ago The reason is that I'm a doofus. I had been typing Time::Local::timegm into some code and my fingers were on auto-repeat.
Please close the bug report. Thank you and apologies.
On 12/27/17 6:29 PM, Dave Rolsky wrote:
If this is a Date::Parse bug I'm a little confused as to why you've reported it here. This is the Time-Local distribution's issue tracker. See https://rt.cpan.org/Dist/Display.html?Name=TimeDate for the TimeDate distribution's bug tracker.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/houseabsolute/Time-Local/issues/5#issuecomment-354216433, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNCwJea1YT9SrjqhhPPZgUo_ywUFDnVks5tEv0ggaJpZM4RN6F4.
Using Date::Parse Version 2.30, Time::Local version 1.25, and perl v5.26.0...
Date::Parse::str2time("January 01, 1967", "GMT") returns 3061065600 which is Jan 1, 2067.
However Time::Local::timegm(0,0,0,1,0,1967) returns the correct result (-94694400), or at least a result which POSIX::strftime thinks is Jan 1, 1967. So at first blush this looks like a bug in str2time() not the timelocal/timegm library.
Anyway, the doc for Date::Parse indicates that dates after 1901 should work. demos.zip
FWIW, both 3061065600 and -94694400 are negative if stored as 32-bit integers. My platform is 64-bit Ubuntu.
I'll attach both a Perl demo script and a small C program which shows the bits in hex (they are both in a .zip file because github won't let me upload a raw ".pl" file).