Wrong timezone names in strftime/strflocaltime for DST
trantor opened this issue · comments
Describe the bug
jq does not print the timezone correctly expanding the %Z in the time format for strftime/strflocaltime when it comes to DST.
To Reproduce
Using the example from the wiki...
$ TZ=Europe/Rome ./jq-linux64 -cn 'now|strflocaltime("%Y-%m-%dT%H:%M:%S %Z")'
"2019-05-28T17:10:54 CET"
$ TZ=Europe/Rome date +"%Y-%m-%dT%H:%M:%S %Z"
2019-05-28T17:10:54 CEST
date reports, correctly, CEST as the timezone taking DST into account. jq does not.
Expected behavior
The output of jq to specify the correct timezone following DST
Environment (please complete the following information):
- Linux Ubuntu 16.04
- jq version 1.6
Huh, I think there's no real difference between strftime and strflocaltime...
Also, strftime(3) in glibc should be doing this for us, but evidently it's not, and the date(1) command is not calling strftime(3) either!
This looks like a bug in glibc, honestly, though we might be able to work around it.
To get at the DST TZ name we need to use localtime_r() and expect a tm_zone name from the broken-down time struct (struct tm), then use that in the formatting of time. So to work around this we'll need an autoconf test for tm_zone, and when it's present... use either a private strftime() or a wrapper that replaces %Z with the tm_zone. Ugh.
This issue exists also in Debian testing in 2021.
Same error on MacOS Monterey version 12.6.
This looks like a bug in function static jv tm2jv(struct tm *tm) and function static int jv2tm(jv a, struct tm *tm). The daylight saving time flag (tm_isdst), which is greater than zero if DST is in effect, is lost.
There is a 10-month-old branch 439cf72 there to fix it. I applied this fix locally. And it works on my machine.
@nicowilliams could we look back at this issue with new development?
Yes this is because the jq representation of broken-down time doesn't have a field for tm_isdst. We also don't look at or set tm_zone nor tm_gmtoff. Should be an easy fix.
Relatedly, mktime drops the fractional part of the seconds.
@nicowilliams #2863 seems to properly address the problem I originally reported