[ISSUE] tzdata ‘right’ timezones aren’t right

[ISSUE] tzdata ‘right’ timezones aren’t right

[dpk]

[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]

New issue by dpk on void-packages repository

https://github.com/void-linux/void-packages/issues/35715

Description:
<!-- Don't request update of package. We have a script for that. https://alpha.de.repo.voidlinux.org/void-updates/void-updates.txt . However, a quality pull request may help. -->
### System

* xuname:  
Void 5.10.92_1 aarch64-musl Unknown uptodate rF
* package:  
tzdata-2021e_1

### Expected behavior

The ‘right’ timezones in `/usr/share/zoneinfo` should include leap second information, but apparently don’t.

```shell
$ 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.

Re: tzdata ‘right’ timezones aren’t right

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/35715#issuecomment-1047213387

Comment:
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?

Re: tzdata ‘right’ timezones aren’t right

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/35715#issuecomment-1047213387

Comment:
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?

Re: tzdata ‘right’ timezones aren’t right

[dpk]

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

New comment by dpk on void-packages repository

https://github.com/void-linux/void-packages/issues/35715#issuecomment-1047638514

Comment:
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.

Re: tzdata ‘right’ timezones aren’t right

[dpk]

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

New comment by dpk on void-packages repository

https://github.com/void-linux/void-packages/issues/35715#issuecomment-1047638514

Comment:
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`

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

[dpk]

[-- Attachment #1: Type: text/plain, Size: 255 bytes --]

New comment by dpk on void-packages repository

https://github.com/void-linux/void-packages/issues/35715#issuecomment-1047643193

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

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

[github-actions]

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

New comment by github-actions[bot] on void-packages repository

https://github.com/void-linux/void-packages/issues/35715#issuecomment-1166172011

Comment:
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.

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

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/35715#issuecomment-1166250639

Comment:
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

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

[paper42]

[-- Attachment #1: Type: text/plain, Size: 148 bytes --]

New comment by paper42 on void-packages repository

https://github.com/void-linux/void-packages/issues/35715#issuecomment-1169758242

Comment:
@sgn

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

[sgn]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/35715#issuecomment-1170205783

Comment:
This is not a bug of `tzutils` or `tzdata`.
It's different in implementation of libc.
On a glibc system:
```sh
$ TZ=right/UTC date -d 'Dec 31 2008 23:59:60'
Wed Dec 31 11:59:60 PM UTC 2008
```

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

[sgn]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/35715#issuecomment-1170205783

Comment:
This is not a bug of `tzutils` or `tzdata`.
It's different in implementation of libc.
On a glibc system:
```sh
$ TZ=right/UTC date -d 'Dec 31 2008 23:59:60'
Wed Dec 31 11:59:60 PM UTC 2008
```

IOW, this is the musl specific behavior.

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

[sgn]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/35715#issuecomment-1170205783

Comment:
This is not a bug of `tzutils` or `tzdata`.
It's different in implementation of libc.
On a glibc system:
```sh
$ TZ=right/UTC date -d 'Dec 31 2008 23:59:60'
Wed Dec 31 11:59:60 PM UTC 2008
```

IOW, this is the musl specific behavior.

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

[sgn]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/35715#issuecomment-1170205783

Comment:
This is not a bug of `tzutils` or `tzdata`.
It's different in implementation of libc.
On a glibc system:
```sh
$ TZ=right/UTC date -d 'Dec 31 2008 23:59:60'
Wed Dec 31 11:59:60 PM UTC 2008
```

On a musl system:
```sh
$ 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.

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

[github-actions]

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

New comment by github-actions[bot] on void-packages repository

https://github.com/void-linux/void-packages/issues/35715#issuecomment-1260299501

Comment:
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.

Re: [ISSUE] [CLOSED] Leap second data in tzdata ‘right’ timezones considered invalid by coreutils and Chrony

[github-actions]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

Closed issue by dpk on void-packages repository

https://github.com/void-linux/void-packages/issues/35715

Description:
<!-- Don't request update of package. We have a script for that. https://alpha.de.repo.voidlinux.org/void-updates/void-updates.txt . However, a quality pull request may help. -->
### 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

```shell
$ 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.