Eric Blake wrote:
The best I can do is search austingroupbugs.net for all bugs containing
strftime, which pulls up a current total of 25 issues.
Thanks for doing that. I read through those issues, and the only one that seems
relevant (i.e., resolved by austingroup but not in Gnulib) is the
On 2/21/19 10:01 PM, Paul Eggert wrote:
> Eric Blake wrote:
>> That used to be true, but now POSIX wants date to behave as if it uses
>> strftime:
>>
>> http://austingroupbugs.net/view.php?id=466
>
> Ah, I didn't know that. Is there a list of recent changes to the POSIX
> spec for strftime
Eric Blake wrote:
That used to be true, but now POSIX wants date to behave as if it uses
strftime:
http://austingroupbugs.net/view.php?id=466
Ah, I didn't know that. Is there a list of recent changes to the POSIX spec for
strftime somewhere? I can look to see which of them have made their
On 2/21/19 9:37 PM, Paul Eggert wrote:
> Eric Blake wrote:
>
>> date -d 0001-01-01 +.%+4C.
>>
>> should produce ".+000.", but currently it produces ".%+4C." because the
>> + flag is unimplemented.
>>
>> See also http://austingroupbugs.net/view.php?id=1184
>
> Surely this bug should be reported
Eric Blake wrote:
date -d 0001-01-01 +.%+4C.
should produce ".+000.", but currently it produces ".%+4C." because the
+ flag is unimplemented.
See also http://austingroupbugs.net/view.php?id=1184
Surely this bug should be reported against strftime, not against 'date'. POSIX
does require
POSIX requires the '+' flag in %C to output padding with leading 0, and
additionally to add a +/- indicator if the minimum field width is larger
than 2 bytes. Thus:
date -d 0001-01-01 +.%+4C.
should produce ".+000.", but currently it produces ".%+4C." because the
+ flag is unimplemented.
See
