-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
fromdate doesn't support fractional seconds #1117
Comments
Thanks for the workaround! This helps parsing Bunyan log records. I use a slightly altered regex to make sure it's a literal dot:
|
This is especially annoying as JSON.stringify produces these strings (e.g. |
To parse iso8601 dates with timezone offset (#1053 ) and fractional seconds, this should work :
|
That'll only work with a positive timezone offset. An improved version that supports all offsets would be:
It's a lot uglier, though. |
@elyscape That works the best !! |
I mean yes, but it works around not being able to parse the date at all. |
Yet another workaround to convert an iso8601 date as "2021-08-11T00:49:38.359Z" to a Unix timestamp in milliseconds. For example, the
Result:
So: |
My use case is processing https://nvd.nist.gov/developers/vulnerabilities data in https://csrc.nist.gov/schema/nvd/api/2.0/cve_api_json_2.0.schema, which seems to be in RFC 3339 format, e.g.:
|
I posted a workaround in another issue that might be interesting #1409 (comment) |
Using jq-1.5 from https://github.com/stedolan/jq/releases/download/jq-1.5/jq-linux64
AFAIK, fractional seconds are valid ISO8601.
jq: error (at <stdin>:1180): date "2016-03-17T17:06:59.764Z" does not match format "%Y-%m-%dT%H:%M:%SZ"
I don't care about the milliseconds, perhaps some people do. That's a harder problem, since you output in an int. But for people who don't care, perhaps you can make a fromdate variant that drops the milliseconds.
The workaround for now for me is:
| sub(".[0-9]+Z$"; "Z") | fromdate
The text was updated successfully, but these errors were encountered: