Closed dpk closed 1 year ago
We have
install -m444 -t ${DESTDIR}/usr/share/zoneinfo iso3166.tab zone1970.tab zone.tab
while e.g. Arch has
install -m644 -t "${pkgdir}"/usr/share/zoneinfo iso3166.tab leap-seconds.list zone1970.tab zone.tab SECURITY # zone.tab is depricated and will go soon
Have you tried building with the latter? in particular, adding leap-seconds.list?
Hmm, curious. Indeed, sha1sum confirms the actual binary data files /usr/share/zoneinfo/right/UTC
are identical on Arch and on Void, both with the 2021e release of the tz database. However, putting leap-seconds.list
in place does not make a difference: date
still does not like the date containing a leap second when its TZ
is set to right/UTC
I’ve updated the report to reflect the actual symptoms, which seemingly don’t have the cause I thought they did
Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.
the command you mention works fine in arch linux. something seems wrong with the way we package tzdata and tzutils, but I could not fix it yet (also, i do not see why we package them separately.) see also the refs in gentoo's package, in particular https://mm.icann.org/pipermail/tz/2015-February/022024.html
@sgn
This is not a bug of tzutils
or tzdata
.
It's different in implementation of libc.
On a glibc system:
$ TZ=right/UTC date -d 'Dec 31 2008 23:59:60'
Wed Dec 31 11:59:60 PM UTC 2008
On a musl system:
$ date --debug -d 'Dec 31 2008 23:59:60'
date: parsed date part: (Y-M-D) 2022-12-31
date: parsed number part: year: 2008
date: parsed time part: 23:59:60
date: input timezone: TZ="right/UTC" environment value
date: using specified time as starting value: '23:59:60'
date: error: invalid date/time value:
date: user provided time: '(Y-M-D) 2008-12-31 23:59:60'
date: normalized time: '(Y-M-D) 2009-01-01 00:00:00'
date: ---- -- -- -- -- --
date: possible reasons:
date: invalid day/month combination;
date: numeric values overflow;
date: missing timezone
date: invalid date ‘Dec 31 2008 23:59:60’
IOW, this is the musl specific behavior.
Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.
System
Void 5.10.92_1 aarch64-musl Unknown uptodate rF
tzdata-2021e_1 coreutils-8.32_4 chrony-4.2_1
Expected behavior
(Test case from the chrony man page)
Actual behavior
This causes Chrony to reject the
leapsectz right/UTC
configuration directive, thusCLOCK_TAI
on Void is always = UTC, at least when using Chrony. Presumably NTPd also doesn’t know where to get leap second data from, because there doesn’t seem to be any in Void.The
/usr/share/zoneinfo/leapseconds
file I’ve seen on other systems is also missing, which could be related.