[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181116213453.GK5150@brightrain.aerifal.cx>
Date: Fri, 16 Nov 2018 16:34:53 -0500
From: Rich Felker <dalias@...c.org>
To: Bartosz Brachaczek <b.brachaczek@...il.com>
Cc: musl@...ts.openwall.com, rafal@...ecki.pl
Subject: Re: Re: [PATCH libc-test] add strptime basic test
On Fri, Nov 16, 2018 at 10:21:01PM +0100, Bartosz Brachaczek wrote:
> On Thu, Nov 15, 2018 at 11:12 AM Rafał Miłecki <zajec5@...il.com> wrote:
>
> > On 15.11.2018 08:34, Rafał Miłecki wrote:
> > > From: Rafał Miłecki <rafal@...ecki.pl>
> > >
> > > Signed-off-by: Rafał Miłecki <rafal@...ecki.pl>
> >
> > I've just tried it with musl (I should have done that before sending a
> > patch) and noticed is fails with:
> >
> > "%Y-%m-%d": for "1991-08-25" expected 1991-08-25T00:00:00 (day 237: Sun)
> > but got 1991-08-25T00:00:00 (day 001: Sun)
> > "%d.%m.%y": for "25.08.91" expected 1991-08-25T00:00:00 (day 237: Sun) but
> > got 1991-08-25T00:00:00 (day 001: Sun)
> > "%D": for "08/25/91" expected 1991-08-25T00:00:00 (day 237: Sun) but got
> > 1991-08-25T00:00:00 (day 001: Sun)
> > "%d.%m.%y": for "21.10.15" expected 2015-10-21T00:00:00 (day 294: Wed) but
> > got 2015-10-21T00:00:00 (day 001: Sun)
> > "%d.%m.%y in %C th": for "10.7.56 in 18th" expected 1856-07-10T00:00:00
> > (day 192: Thu) but got 1856-07-10T00:00:00 (day 001: Sun)
> >
> > which I didn't expect.
> >
> > It's because I assumed glibc behavior which sets tm_wday and tm_yday.
> >
> > The man says:
> > "In principle, this function does not initialize tm but stores only the
> > values specified."
> >
> > There is a glibc behavior however:
> > "Details differ a bit between different UNIX sys-tems. The glibc
> > implementation does not touch those fields which are not explicitly
> > specified, except that it recomputes the tm_wday and tm_yday field if
> > any of the year, month, or day elements changed."
> >
> > I guess a correct test should allow any behavior and don't test tm_wday
> > and tm_yday fields.
> >
> >
> > It also fails with:
> >
> > "%F": failed to parse "1856-07-10"
> > "%s": failed to parse "683078400"
> > "%z": failed to parse "+0200"
> > "%z": failed to parse "-0530"
> > "%z": failed to parse "-06"
> >
> > but that's expected due to unimplemented %F %s and %z.
> >
>
> I cannot find anything in the normative text that would suggest that
> recomputing tm_wday and/or tm_yday is required, but interestingly enough,
> the strptime example that is used in POSIX seems to rely on that. See:
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html.
> That example does not produce expected output using musl.
>
> Possibly something that should be clarified in POSIX?
Yes, I think this calls for a defect report/request for
interpretation. Even if one intends that tm_[wy]day be updated, there
is no canonical correct way to do it. Certainly it can't happen
without sufficiently many constraints to determine the value, and it's
not clear what would happen when %a, %w, etc. are also present.
Overall, strptime is severely under-specified, and musl tends to err
on the side of not doing anything it's not specified to do, since it
could turn out that such action is contrary to intended interpretation
or future changes to the standard, in which case applications
depending on the behavior could be broken by fixing musl to conform.
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.
