tags 14545 fixed
close 14545
stop
(triaging old bugs)
This was fixed in:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=17bbf6ce44eb543a95695fa9d2cbd70fb52c6f42
Marking as "fixed" and closing.
-assaf
On 06/04/2013 09:55 AM, Jordon Kalilich wrote:
> Thus spake Paul Eggert on 06/04/2013 12:10 AM:
>> At any rate, the --iso-8601 option has been deprecated since 2005.
>
> Why is it deprecated? I don't recall seeing it in the man page until recently,
> and I've noticed an increase in the use of ISO
Paul Eggert wrote:
> On 06/02/2013 09:13 PM, Jordon Kalilich wrote:
>> The output mostly follows the ISO 8601:2004 extended format but
>> fails to include
>> a colon in the time zone offset, as required by section 4.3.2 "Complete
>> representations" and section 4.3.3 "Representations other than co
Thus spake Paul Eggert on 06/04/2013 12:10 AM:
> At any rate, the --iso-8601 option has been deprecated since 2005.
Why is it deprecated? I don't recall seeing it in the man page until recently,
and I've noticed an increase in the use of ISO 8601 over the past few years.
This option seems like it
On 06/02/2013 09:13 PM, Jordon Kalilich wrote:
> The output mostly follows the ISO 8601:2004 extended format but fails to
> include
> a colon in the time zone offset, as required by section 4.3.2 "Complete
> representations" and section 4.3.3 "Representations other than complete."
If memory serve
date uses an inconsistent format when the options
--iso-8601=[hours|minutes|seconds|ns] are specified. Example:
$ date --iso-8601=seconds
2013-06-02T20:07:03-0700
The output mostly follows the ISO 8601:2004 extended format but fails to include
a colon in the time zone offset, as required by secti