[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160331160647.GV21636@brightrain.aerifal.cx>
Date: Thu, 31 Mar 2016 12:06:47 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Bug in timezone handling (new zonename format like
'<+04>-4' )
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@...nWrt:~# cat /etc/TZ
> EET-2EEST,M3.5.0/3,M10.5.0/4
> root@...nWrt:~# uptime
> 11:00:52 up 18:17, load average: 0.43, 0.13, 0.11
> root@...nWrt:~# date
> Wed Mar 30 11:00:55 EEST 2016
>
> "new zone" is handle wrongly:
> Europe/Astrakhan
> root@...nWrt:~# cat /etc/TZ
> <+04>-4
> root@...nWrt:~# uptime
> 08:02:52 up 18:19, load average: 0.17, 0.18, 0.13
> root@...nWrt:~# 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
