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/date-parse.t started to fail in 2020 #14

Closed
eserte opened this issue Jan 1, 2020 · 5 comments
Closed

t/date-parse.t started to fail in 2020 #14

eserte opened this issue Jan 1, 2020 · 5 comments

Comments

@eserte
Copy link

@eserte eserte commented Jan 1, 2020

See subject. Excerpt of test log:

#   Failed test 'successful 0 parse: 3155760000'
#   at t/date-parse.t line 123.
#          got: '2070-01-01'
#     expected: '1970-01-01'
# Looks like you failed 1 test of 733.
t/date-parse.t ........... 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/733 subtests 

http://matrix.cpantesters.org/?dist=Date-Easy%200.09;reports=1#sl=7,1 also shows that reports generated since 2020-01-01 are fail reports.

@barefootcoder

This comment has been minimized.

Copy link
Owner

@barefootcoder barefootcoder commented Jan 7, 2020

This is remarkably similar to #12, where a bug in str2time caused a test failure (which did not indicate a failure in the module). This time, I'm bitten by timelocal's stupid "rolling century" because now the beginning of the Unix epoch is 50 years ago. So I'm trying to convert 0 to the local time via timelocal gmtime 0, and stupid gmtime returns 70 for the year, and stupid timelocal (now) thinks that means 2070 instead of 1970. My goto fix for these sorts of problems (dropping in timelocal_modern) doesn't fix it, because that just makes it think I want the year 70AD. :-/

I'm going to need to ponder if I even really need this test and, if so, how best to fix it. Thx as always for the prompt report. (And, remember: it's not a bug in the module, just the test.)

@eserte

This comment has been minimized.

Copy link
Author

@eserte eserte commented Jan 7, 2020

Unfortunately timelocal/timegm are not the inverse functions to localtime/gmtime. You have to add 1970 to the year part returned by localtime/gmtime.

@barefootcoder

This comment has been minimized.

Copy link
Owner

@barefootcoder barefootcoder commented Jan 7, 2020

Unfortunately timelocal/timegm are not the inverse functions to localtime/gmtime.

Indeed. I just found (or perhaps refound) this article, which explains it pretty well.

I'm not entirely sure I need to keep this test anyway, but I think I'll fix it as an exercise. I want to do one other feature add while I'm in there, but hopefully I'll have something in the next day or so.

And perhaps I can squeeze a blog post out of it as well. :-)

barefootcoder added a commit that referenced this issue Jan 12, 2020
@barefootcoder

This comment has been minimized.

Copy link
Owner

@barefootcoder barefootcoder commented Jan 12, 2020

(Sorry for the delay; my laptop completely melted down on Wednesday and I'm just now back to a semblance of normality.)

Okay, fix is uploaded as 0.09_01; we'll see what CPAN Testers has to say. Working on the blog post now. :-)

@barefootcoder

This comment has been minimized.

Copy link
Owner

@barefootcoder barefootcoder commented Jan 15, 2020

Okay, 0.10 is available on CPAN now. This issue should be resolved.

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.