[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <699b8fe9-4693-8f71-c321-452c765f26a3@iki.fi>
Date: Thu, 31 Mar 2016 19:47:16 +0300
From: Hannu Nyman <hannu.nyman@....fi>
To: musl@...ts.openwall.com
Subject: Re: Bug in timezone handling (new zonename format like
'<+04>-4' )
On 31.3.2016 19:06, Rich Felker wrote:
> 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.)
>>
>> ...
>>
>> "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
As far as I can see, the new timezones are according to the POSIX specs:
just the "quoted std + offset"
And musl has some handling for the "quoted form", e.g. in the getname function:
http://git.musl-libc.org/cgit/musl/tree/src/time/__tz.c#n82
But apparently not all functions utilize that, or something else goes wrong.
Sadly I can't offer you more examples. I just thought to highlight the issue
after noticing it and determined it to be likely a musl issue.
My use case is with Openwrt+musl, which in practice means busybox utils
combined with musl. As the older Openwrt CC15.05.1 works ok (with
busybox+uClibc), I think that this is musl-specific. I haven't checked from
busybox sources how e.g. "uptime" gets exactly handled and which musl
functions it calls. But almost the same busybox version behaves ok with
uClibc but fails with musl.
So far this issue only concerns three small timezones in Russia, but is all
new zones get introduced this way, the issue may grow in importance.
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.
