fromdateiso8601 not inverse of todateiso8601

[frans42]

I observe weird behaviour with the same version of jq on different distros:

On CentOS 7:

> cat /etc/redhat-release 
CentOS Linux release 7.9.2009 (Core)
> jq --version
jq-1.6
> # date stamp with daylight saving on:
> jq 'fromdateiso8601 - (fromdateiso8601|todateiso8601|fromdateiso8601)' <<<'"2024-04-04T20:00:18Z"'
-3600 # <<< Wait, what???
> # date stamp with daylight saving off:
> jq 'fromdateiso8601 - (fromdateiso8601|todateiso8601|fromdateiso8601)' <<<'"2024-01-04T20:00:18Z"'
0

Same test on Ubuntu 20.04:

> cat /etc/debian_version
bullseye/sid
> jq --version
jq-1.6
> jq 'fromdateiso8601 - (fromdateiso8601|todateiso8601|fromdateiso8601)' <<<'"2024-04-04T20:00:18Z"'
0
> jq 'fromdateiso8601 - (fromdateiso8601|todateiso8601|fromdateiso8601)' <<<'"2024-01-04T20:00:18Z"'
0

It seems to be linked against the same libraries:

Centos 7:

[root@gnosis date-stamps]# ldd /bin/jq
	linux-vdso.so.1 =>  (0x00007ffd86a70000)
	libjq.so.1 => /usr/lib64/libjq.so.1 (0x00007f6a60914000)
	libm.so.6 => /usr/lib64/libm.so.6 (0x00007f6a60612000)
	libonig.so.5 => /usr/lib64/libonig.so.5 (0x00007f6a6038f000)
	libc.so.6 => /usr/lib64/libc.so.6 (0x00007f6a5ffc1000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6a60b61000)

Ubuntu 20.04:

frank@frank-UX303UA:~$ ldd /usr/bin/jq
	linux-vdso.so.1 (0x00007ffd9f197000)
	libjq.so.1 => /usr/lib/x86_64-linux-gnu/libjq.so.1 (0x00007fe8c5fde000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe8c5dec000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe8c5c9d000)
	libonig.so.5 => /usr/lib/x86_64-linux-gnu/libonig.so.5 (0x00007fe8c5c0e000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fe8c605b000)

Could be an issue with a distro library version. Any idea where the problem might be?

[frans42]

Seems to affect jq on RHEL distros over a larger range of major versions:

> jq 'fromdateiso8601 - (fromdateiso8601|todateiso8601|fromdateiso8601)' <<<'"2024-04-04T20:00:18Z"'
-3600
> cat /etc/redhat-release 
CentOS Stream release 8
> jq --version
jq-1.6

[frans42]

I forgot to mention this: the problem occurs only with date stamps in local summer time:

> jq 'fromdateiso8601 - (fromdateiso8601|todateiso8601|fromdateiso8601)' <<<'"2024-04-04T20:00:18Z"'
-3600
> jq 'fromdateiso8601 - (fromdateiso8601|todateiso8601|fromdateiso8601)' <<<'"2024-02-04T20:00:18Z"'
0
> date
Mon Apr 29 09:26:20 CEST 2024
> timedatectl 
      Local time: Mon 2024-04-29 09:27:05 CEST
  Universal time: Mon 2024-04-29 07:27:05 UTC
        RTC time: Mon 2024-04-29 07:27:06
       Time zone: Europe/Copenhagen (CEST, +0200)
     NTP enabled: no
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2024-03-31 01:59:59 CET
                  Sun 2024-03-31 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2024-10-27 02:59:59 CEST
                  Sun 2024-10-27 02:00:00 CET

[wader]

Thanks, that is good to know. I tried to reproduce with centos:7 docker image (with macOS as host) but i'm failing to setup a locale with CEST. I don't know much about redhat/centos so i'm a bit lost. Could you try and possibly give some reproduction steps like a Dockerfile? that would help a lot. Also i noticed that jq i managed to install via yum is jq 1.5. Are you using https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64?

For sanity could you also try with jq 1.7.1 and jq master?

[frans42]

So far I'm using the distro versions. I'm not sure if it is possible to reproduce this within a container, the time management is likely inside the kernel and you might need a full KVM for reproduction. I will give it a go a soon as I have time, hopefully within the next 2 weeks. I will also try to compare the distro version with a build from source.

[wader]

That would be great. Think it will be hard and time consuming to debug this for someone without reproduction steps

[jmoldow]

I believe this is a duplicate of #2001 and can probably be closed, since it is fixed in jq 1.7 (though that version still isn't released to Debian and probably other systems as well).

[frans42]

Reading through the related reports it looks very much like its a duplicate. Even the workaround is the same. I hope 1.7 will be packaged soon. Good that it was already addressed, didn't have much time to investigate this so far but it was still on my list.