[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150814093431.GD27440@port70.net>
Date: Fri, 14 Aug 2015 11:34:32 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Jan V??el?k <jan.vcelak@....cz>
Cc: musl@...ts.openwall.com
Subject: Re: strptime() lacks support for %z
* Jan V??el?k <jan.vcelak@....cz> [2015-08-14 10:00:23 +0200]:
> On Thursday, August 13, 2015 10:06:50 PM Szabolcs Nagy wrote:
> > the problem with parsing timezones is that it's not posix
> > so the desired semantics is not clear (struct tm has no
> > tz field in posix and it is not obvious how that should
> > be treated in other apis that use struct tm.. glibc does
> > something but it should be verified to give consistent
> > behaviour if we add this to musl and there might be parsing
> > corner cases when %z is not surrounded by spaces..).
>
> I know it's not specified in POSIX strptime, however it is specified in
> strftime. I'm not sure how strictly do you want to stick to POSIX, but it
> seems reasonable to me to have the equivalent format support in both
> functions, so you can write the time stamp and parse it back.
>
> Anyway, the format in strftime is simple and on fixed width, +hhmm or -hhmm.
>
strftime uses tzset (timezone from TZ) but strptime cannot
set TZ so it must put the timezone somewhere else.
so strptime can't be consistent with strftime.
with tz in struct tm, mktime/localtime no longer roundtrip.
> So what do you suggest? Should we make a workaround for this in our project
> code? Or will you consider supporting non-POSIX format specifier in strptime
> in musl?
if you want portable code then you cannot rely on the
libc supporting %z, but otherwise it seems to be a
reasonable extension, just make sure the implementation
does not break any conforming code that does not use %z.
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.
