Re: Bug in timezone handling (new zonename format like '<+04>-4' )

[Rich Felker <dalias@libc.org>]

On Thu, Mar 31, 2016 at 06:50:14PM +0300, Hannu Nyman wrote:
> The IANA timezone zoneinfo maintainers have decided to introduce new
> timezones in a simplified format with 2016b zoneinfo.
> No more invented name strings, but just the time offset inside <...>
> This seems to break musl.
> 
> http://mm.icann.org/pipermail/tz-announce/2016-March/000036.html
>      New zones Europe/Astrakhan and Europe/Ulyanovsk ... Asia/Barnaul ...
>      As a trial of a new system that needs less information to be
> made up, the new zones use numeric time zone abbreviations like
> "+04" instead of invented abbreviations like "ASTT".
> 
> I have tested with Openwrt trunk using musl (with Linux kernel 4.1)
> and older uClibc-based Openwrt CC15.05.1.
> The uClibc-based system uses the new zones ok, but the musl-based
> build behaves badly, as it defaults to GMT and shows the zonename as
> '+04>-4'. (This is when full zoneinfo files are not installed and
> just the TZ variable is used.)
> 
> Examples at https://github.com/openwrt/luci/issues/675
> 
> (note: Openwrt patches musl to store TZ in /etc/TZ instead of an env
> variable, but that should have no impact in the displayed timezone.)
> 
> Example with musl:
> 
> old zone is ok:
> Europe/Helsinki
> root@OpenWrt:~# cat /etc/TZ
> EET-2EEST,M3.5.0/3,M10.5.0/4
> root@OpenWrt:~# uptime
>  11:00:52 up 18:17,  load average: 0.43, 0.13, 0.11
> root@OpenWrt:~# date
> Wed Mar 30 11:00:55 EEST 2016
> 
> "new zone" is handle wrongly:
> Europe/Astrakhan
> root@OpenWrt:~# cat /etc/TZ
> <+04>-4
> root@OpenWrt:~# uptime
>  08:02:52 up 18:19,  load average: 0.17, 0.18, 0.13
> root@OpenWrt:~# date
> Wed Mar 30 08:02:59 +04>-4 2016
> (That should be Helsinki+1  (= +2 -DST) = 12:02:59)

I thought this was some nonstandard extension conflicting with
standard handling of the TZ variable, but in fact it's documented in
current POSIX as a quoted form:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

Does the specification there agree with your expectations of how it
should behave? Do you have any other references I could look at on how
this is supposed to be used?

Rich