On 15.11.2018 08:34, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.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.