On Thu, Nov 15, 2018 at 11:12 AM Rafał Miłecki wrote: > On 15.11.2018 08:34, Rafał Miłecki wrote: > > From: Rafał Miłecki > > > > Signed-off-by: Rafał Miłecki > > 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?