Bugs in strftime

["Dennis Wölfing" <denniswoelfing@gmx.de>]

Hi,

I recently wrote a test for strftime and ran it on multiple
implementations. The source code of the test is available at [1]. The
test results (also for other implementations) are available at [2].

On musl my test currently reports 8 failures. These are caused by two bugs:

1. For the + flag, musl does currently only prefix the output by a plus
when the number without padding consumes more the 4 bytes (2 for %C).
However according to the POSIX standard, there should be a leading plus
when "the field being produced consumes more than four bytes" (2 for
%C). The padding is part of the field being produced.
So for example %+3C should always have a leading plus for any
non-negative years because the field then always has a width of at least
3 bytes. (There is also an example in the POSIX standard where "%+5Y"
produces "+0270" for the year 270.)

This bug is causing these failures:
> "%+3C": expected "+20", got "020"
> "%+11F": expected "+2016-01-03", got "02016-01-03"
> "%+5G": expected "+2015", got "02015"
> "%+5Y": expected "+2016", got "02016"
> "%+5Y": expected "+0000", got "00000"

2. %F produces incorrect results for the year 0 when a field width is
specified. It seems like in this case strftime does not output the year
and applies the padding to the month.

This bug is causing these failures:
> "%01F": expected "0-02-23", got "2-23"
> "%06F": expected "0-02-23", got "002-23"
> "%010F": expected "0000-02-23", got "0000002-23"

The tests were run on musl 1.1.18 on Alpine Linux.

[1] https://github.com/dennis95/dennix/blob/master/libc/test/test-strftime.c

[2]
https://gist.github.com/dennis95/b4869b5cbb3c21e15e409afb827354a5#file-musl-1-1-18-alpine-linux-x86_64