Re: [PATCH] ISO 8601 basic format and decimal hours, minutes

[Alex Eulenberg]

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