Leap second data in tzdata ‘right’ timezones considered invalid by coreutils and Chrony

[dpk]

System

• xuname:
  Void 5.10.92_1 aarch64-musl Unknown uptodate rF
• package:
  tzdata-2021e_1
  coreutils-8.32_4
  chrony-4.2_1

Expected behavior

$ TZ=right/UTC date -d 'Dec 31 2008 23:59:60'
Wed Dec 31 23:59:60 UTC 2008

(Test case from the chrony man page)

Actual behavior

date: invalid date ‘Dec 31 2008 23:59:60’

This causes Chrony to reject the leapsectz right/UTC configuration directive, thus CLOCK_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.

[dkwo]

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?

[dpk]

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

[dpk]

I’ve updated the report to reflect the actual symptoms, which seemingly don’t have the cause I thought they did

[github-actions]

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.

[dkwo]

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

[paper42]

@sgn

[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.

[github-actions]

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.