Skip to content
New issue

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

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

Already on GitHub? # to your account

test failures on macOS 10.12 #1415

Closed
chdiza opened this issue May 19, 2017 · 11 comments
Closed

test failures on macOS 10.12 #1415

chdiza opened this issue May 19, 2017 · 11 comments

Comments

@chdiza
Copy link

chdiza commented May 19, 2017

When trying to build from master on 10.12.4, I get the following test failure: https://gist.github.com/chdiza/762c86adaf40bfef2bdd889485eaa547

The test-suite.log is here: https://gist.github.com/chdiza/a28e34301fe058b8759ce092a525a704

This happens whether or not I build against the enclosed oniguruma.

@nicowilliams
Copy link
Contributor

That's... strptime() being broken on OS X. Fantastic. I guess I get to write code to deal with that. Or not.

@nicowilliams
Copy link
Contributor

We already have an issue open for OS X strptime() issues, #929.

See also http://stackoverflow.com/questions/31984002/why-does-strptime-behave-differently-on-osx-and-on-linux. The OS X man page for strptime is woefully brief. It seems that we need to compute tm_wday and tm_yday ourselves.

I don't think I'll be fixing this anytime soon, though I'll probably paper this over in the test.

@nicowilliams
Copy link
Contributor

Ahhh, right, timegm() will set tm_wday and tm_yday.

@nicowilliams
Copy link
Contributor

@chdiza I've pushed an attempt to fix this. Can you please test.

@nicowilliams nicowilliams reopened this May 21, 2017
@chdiza
Copy link
Author

chdiza commented May 21, 2017

@nicowilliams Thanks. I tested it and I still get the same test failure, with the same test-suite.log.

@nicowilliams
Copy link
Contributor

@chdiza I've pushed c538237 to try once more to fix this. Can you check it?

@chdiza
Copy link
Author

chdiza commented May 21, 2017

@nicowilliams Getting closer, at least! The same test fails, but this time the testsuite.log says something different:

====================================================
   jq 1.5rc2-243-gc538237-dirty: ./test-suite.log
====================================================

# TOTAL: 7
# PASS:  6
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/optionaltest
========================

Testing '[strptime("%Y-%m-%dT%H:%M:%SZ")|(.,mktime)]' at line number 4
Testing 'last(range(365 * 199)|("1900-03-01T01:02:03Z"|strptime("%Y-%m-%dT%H:%M:%SZ")|mktime) + (86400 * .)|strftime("%Y-%m-%dT%H:%M:%SZ")|strptime("%Y-%m-%dT%H:%M:%SZ"))' at line number 9
*** Insufficient results for test at line number 11: last(range(365 * 199)|("1900-03-01T01:02:03Z"|strptime("%Y-%m-%dT%H:%M:%SZ")|mktime) + (86400 * .)|strftime("%Y-%m-%dT%H:%M:%SZ")|strptime("%Y-%m-%dT%H:%M:%SZ"))
Testing 'strftime("%A, %B %e, %Y")' at line number 14
2 of 3 tests passed (0 malformed)
FAIL tests/optionaltest (exit status: 1)

@chdiza
Copy link
Author

chdiza commented May 21, 2017

Hopefully that's an easy fix. If not, instead of spending even more time on this it'd be just fine with me if this particular test is simply skipped on macOS.

@nicowilliams
Copy link
Contributor

@chdiza Yeah, maybe.

Can you show us the output of this:

$ jq -n 'last(range(365 * 199)|("1900-03-01T01:02:03Z"|strptime("%Y-%m-%dT%H:%M:%SZ")|mktime) + (86400 * .)|strftime("%Y-%m-%dT%H:%M:%SZ")|strptime("%Y-%m-%dT%H:%M:%SZ"))' 

I mean, the test log implies it output nothing. But I'm curious if there were any errors.

@nicowilliams nicowilliams reopened this May 21, 2017
@chdiza
Copy link
Author

chdiza commented May 22, 2017

The output is:

jq: error (at <unknown>): invalid gmtime representation

@yoichi
Copy link
Contributor

yoichi commented Oct 27, 2017

c538237 breaks 1st test of optional.test on macos

$ echo '"2015-03-05T23:51:47Z"' | jq 'strptime("%Y-%m-%dT%H:%M:%SZ")|strftime("%A, %B %e, %Y")'
"Wednesday, March  5, 2015"

It's Thursday, correctly.

davidfetter pushed a commit to davidfetter/jq that referenced this issue Oct 27, 2017
OS X (and *BSD) strptime() does not set tm_wday nor tm_yday unless
corresponding format options are used.  That means we must call timegm()
to set them.
davidfetter pushed a commit to davidfetter/jq that referenced this issue Oct 27, 2017
strptime() on OS X and *BSDs (reputedly) does not set tm_wday and
tm_yday unless corresponding %U and %j format specifiers were used.
That can be... surprising when one parsed year, month, and day anyways.
Glibc's strptime() conveniently sets tm_wday and tm_yday in those cases,
but OS X's does not, ignoring them completely.

This commit makes jq compute those where possible, though the day of
week computation may be wrong for dates before 1900-03-01 or after
2099-12-31.
@chdiza chdiza closed this as completed Apr 26, 2023
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

3 participants