Posting my response now that I have I finally got the copyright
assignment, including employer disclaimer, finalized.
Original patch posted Feb 19, 2019, for reference:
https://lists.gnu.org/archive/html/bug-gnulib/2019-02/msg00041.html
Now responding to Assaf's comments from April of last year.
On 2019-04-07 00:20 PDT, Assaf Gordon wrote:
Adding new accepted formats is good,
but rejecting (or changing the meaning of) currently-accepted formats
is a much more problematic decision due to breaking existing programs.
I think that before continuing, it should be discussed and decided
whether this is acceptable or not (Paul, Jim?).
Regarding the "breaking" change. The format that breaks is not included
in the current test suite, and I think is unlikely to occur in actual
existing programs:
YYYYMMDD HH-ZZ
Note that the following other related formats are currently rejected or
give incorrect results anyway:
YYYYMMDD HHMM-ZZ (incorrect result)
YYYYMMDD HHMMSS-ZZ (incorrect result)
YYYYMMDDTHHMM-ZZ (rejected)
YYYYMMDDTHHMMSS-ZZ (rejected)
What my patch does is to allow the currently-rejected ISO-compliant
strings ("T" separator) to be accepted and interpreted correctly, while
removing altogether the acceptance of a marginal class of strings (" "
separator, no dashes or colons, in conjunction with zone offset), which
is currently handled unreliably anyway.
If we do go forward this this breaking-change, we should make sure
to announce it and communicate it properly to users of coreutils'
date(1).
Agreed.
As a compromise, note that the 'parse_datetime2' function accepts
'flags' parameter (added in recent years). Perhaps a flag could
be specified if 'T' is always iso8601 or military time
(and then add an option to date(1) ).
I would rather not have to set a flag for the sake of this corner case.
I suppose it would be impossible to confirm that no one is actually
using this format, but perhaps there is some way we could be satisfied
that the existing poor support for this marginal format can be dropped.
--Alex
