On 2/21/19 9:15 AM, Bernhard Voelker wrote:
> On 2/19/19 2:53 PM, Eric Blake wrote:
>> [...] - just blindly set
>> opterr without worrying about restoring it.
>
> You are both right, sorry for the confusion.
> Adjusted patches attached.
>
> I added some more test cases as well.
> Finally, I
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
On 2/19/19 2:53 PM, Eric Blake wrote:
> [...] - just blindly set
> opterr without worrying about restoring it.
You are both right, sorry for the confusion.
Adjusted patches attached.
I added some more test cases as well.
Finally, I documented the change in 'yes' in NEWS regarding:
$ yes a --
