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

OS X "strptime" results inconsistent with Linux #929

Open
vielmetti opened this issue Aug 26, 2015 · 2 comments
Open

OS X "strptime" results inconsistent with Linux #929

vielmetti opened this issue Aug 26, 2015 · 2 comments

Comments

@vielmetti
Copy link

The task I'm trying to accomplish is to pull in data from a data source that has timestamps but that doesn't specify time zone or daylight savings time. Ideally I'll get an accurate "seconds since the epoch" when I'm done parsing.

The problem is that I get different results depending on whether I'm on OS X Mavericks or on Linux Ubuntu. Here's a small sample script; I'm in EDT:

date | sed -e 's/^/\"/' -e 's/$/\"/' | ./jq '(strptime("%a %b %d %H:%M:%S %Z %Y")|mktime) - now'

(feed the output of the date command into jq as a string, parse the time, subtract current time, result in seconds).

On OS X I typically get output like -14400.879971027374 which corresponds to 4 hours off.

On Ubuntu I get output like -0.6590850353240967 which is less than a second off.

If I had to guess, there's something to do with this in the OS X docs:

     The %Z format specifier only accepts time zone abbreviations of the local
     time zone, or the value "GMT".  This limitation is because of ambiguity
     due to of the over loading of time zone abbreviations.  One such example
     is EST which is both Eastern Standard Time and Eastern Australia Summer
     Time.

but not in the Ubuntu docs, which reference glibc:

       %Z     The timezone name.
@vielmetti
Copy link
Author

I suspect that the test for this issue lives here

https://github.com/stedolan/jq/blob/b8f71d365927416c7f453f5d5e969a51a6073c4b/tests/jq.test#L1159

As for fixing it, either "this is documented behavior" (OK) or perhaps somehow build and load the GNU datetime libraries (to give predictable and testable behavior).

@nicowilliams
Copy link
Contributor

Is there a GNU datetime library? We'd not link against it if it's GPL though. Anyways, yes, we rely on the C library for datetime support, so if the OS' C library implementation's strptime() does not support the %Z input field descriptor, well, there's nothing we can do. They should all support UTC though.

On Ubuntu I'm getting this:

$ ./jq -n --arg cdt "$(date)" --arg edt "$(date|sed s/CDT/EDT/)" '($cdt,$edt)|strptime("%a %b %d %H:%M:%S %Z %Y")|mktime - now'
-18000.827734947205
-18000.828102111816
$ 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants