I noticed that all dates where displayed as UTC on a system I use (where I deployed a tool where I decided to test Jiff). Using tzdb-bundle-always fixes the issue, but I still thought it was strange that it failed since all the date time tools of the system show timezone.
$ date
Thu Nov 28 21:52:38 AEDT 2024
and
$ timedatectl
Local time: Thu 2024-11-28 21:52:56 AEDT
Universal time: Thu 2024-11-28 10:52:56 UTC
RTC time: Thu 2024-11-28 20:52:56
Time zone: Australia/Sydney (AEDT, +1100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
So, to be a bit helpful, I compiled a simple binary, that just prints Zoned::now(), and then I enabled the logging feature of jiff. And this is the output:
$ ./jifftest
2024-11-28 21:46:38.609 - opening zoneinfo database at /usr/share/zoneinfo
2024-11-28 21:46:38.609 - found file /usr/share/zoneinfo/zone.tab that isn't TZif since its first four bytes are "# tz"
2024-11-28 21:46:38.609 - found file /usr/share/zoneinfo/leapseconds that isn't TZif since its first four bytes are "# Al"
2024-11-28 21:46:38.609 - found file /usr/share/zoneinfo/zone1970.tab that isn't TZif since its first four bytes are "# tz"
2024-11-28 21:46:38.609 - found file /usr/share/zoneinfo/tzdata.zi that isn't TZif since its first four bytes are "# ve"
2024-11-28 21:46:38.609 - found file /usr/share/zoneinfo/iso3166.tab that isn't TZif since its first four bytes are "# IS"
2024-11-28 21:46:38.610 - found file /usr/share/zoneinfo/leap-seconds.list that isn't TZif since its first four bytes are "#\n#\t"
2024-11-28 21:46:38.634 - initialized global time zone database: TimeZoneDatabase(system=ZoneInfo(/usr/share/zoneinfo))
2024-11-28 21:46:38.634 - checked TZ environment variable but found nothing
2024-11-28 21:46:38.634 - extracted "Australia/Sydney" from symlink target "/usr/share/zoneinfo/Australia/Sydney" for path "/etc/localtime" and assuming it is an IANA time zone name
2024-11-28 21:46:38.634 - failed to cache time zone from file /usr/share/zoneinfo/Australia/Sydney: /usr/share/zoneinfo/Australia/Sydney: transition second value -576460752303423488 is out of range: parameter 'second' with value -576460752303423488 is not in the required range of -377705023201..=253402207200
2024-11-28 21:46:38.634 - using "Australia/Sydney" symlink target "/usr/share/zoneinfo/Australia/Sydney" for path "/etc/localtime" as time zone name, but failed to find time zone with that name in zoneinfo database TimeZoneDatabase(system=ZoneInfo(/usr/share/zoneinfo))
2024-11-28 21:46:38.634 - failed to find time zone name using Unix-specific heuristics, attempting to read /etc/localtime as unnamed time zone
2024-11-28 21:46:38.634 - failed to read /etc/localtime as unnamed time zone: found invalid TZif data at "/etc/localtime": transition second value -576460752303423488 is out of range: parameter 'second' with value -576460752303423488 is not in the required range of -377705023201..=253402207200
2024-11-28 21:46:38.634 - failed to get system time zone, falling back to UTC: failed to find system time zone
Date: 2024-11-28T10:46:38.608926605+00:00[UTC]
It seems that it actually finds the timezone, but the offset is not in the expected format. So, it seems that RHEL 8 (and its derivates) might be using another format for the timezone offsets.
And some basic info about the system:
The kernel info:
$ uname -a
Linux NPCMAMDEVMAY01 4.18.0-477.21.1.el8_8.x86_64 #1 SMP Tue Aug 8 21:30:09 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
And the distribution:
$ cat /etc/redhat-release
Rocky Linux release 8.8 (Green Obsidian)
I noticed that all dates where displayed as UTC on a system I use (where I deployed a tool where I decided to test Jiff). Using
tzdb-bundle-alwaysfixes the issue, but I still thought it was strange that it failed since all the date time tools of the system show timezone.and
So, to be a bit helpful, I compiled a simple binary, that just prints
Zoned::now(), and then I enabled the logging feature of jiff. And this is the output:It seems that it actually finds the timezone, but the offset is not in the expected format. So, it seems that RHEL 8 (and its derivates) might be using another format for the timezone offsets.
And some basic info about the system:
The kernel info:
And the distribution: