Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

t/datetime.t started to fail in 2019 #12

Closed
eserte opened this issue Jan 1, 2019 · 3 comments
Closed

t/datetime.t started to fail in 2019 #12

eserte opened this issue Jan 1, 2019 · 3 comments

Comments

@eserte
Copy link

@eserte eserte commented Jan 1, 2019

The test suite started to fail on my smokers today:

#   Failed test 'successfully constructed (7args local): 19691231235959'
#   at t/datetime.t line 81.
#          got: '1969-12-31 23:59:59.000 UTC'
#     expected: '2069-12-31 23:59:59.000 UTC'

#   Failed test 'successfully constructed (7args GMT): 19691231235959'
#   at t/datetime.t line 81.
#          got: '1969-12-31 23:59:59.000 UTC'
#     expected: '2069-12-31 23:59:59.000 UTC'

#   Failed test 'successfully constructed (7args UTC): 19691231235959'
#   at t/datetime.t line 81.
#          got: '1969-12-31 23:59:59.000 UTC'
#     expected: '2069-12-31 23:59:59.000 UTC'
# Looks like you failed 3 tests of 71.
t/datetime.t ............. 
Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/71 subtests 

It looks like 2069 is now nearer than 1969, and picked by some heuristics in Date::Easy.

@barefootcoder

This comment has been minimized.

Copy link
Owner

@barefootcoder barefootcoder commented Apr 13, 2019

Well, I'm just now finding time to take a look at this ... sorry for the delay! The good news is, this is not actually a problem with the module so much as a problem with the tests.

It looks like 2069 is now nearer than 1969, and picked by some heuristics in Date::Easy.

This is actually a bug in str2time, which Date::Easy uses for certain things, but in this particular case it's only my use of it as a "trusted" way to verify that I'm coming up with the right answer in this unit test. And, as it turns out, I'm coming up with the right answer, but my "trusted" source probably shouldn't be trusted quite so much. :-(

(Side note: I would report this as an upstream bug, but there are already quite a few reports on it: RT/84075, RT/105031, RT/124509, RT/53413, and RT/128158, at least.)

So I'm going to have to come up with a better way to check my answers. I'll try to get that out in the next few days. Thx for the report!

@barefootcoder

This comment has been minimized.

Copy link
Owner

@barefootcoder barefootcoder commented Apr 16, 2019

Okay, CPAN Testers seemed fine with my fix, so I'm releasing 0.07 to CPAN, which should fix it. Closing this out.

@barefootcoder

This comment has been minimized.

Copy link
Owner

@barefootcoder barefootcoder commented Jun 29, 2019

Apparently 0.07 was never indexed on the PAUSE side; I've fixed that now, so it should fixed as of 0.08. (To be clear, it was fixed in 0.07 too, but you couldn't get that version from a CPAN client without extraordinary measures. Mainly leaving this note here as a reminder to myself.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.