Re: [PATCH] ISO 8601 basic format and decimal hours, minutes
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:
MMDD HH-ZZ
Note that the following other related formats are currently rejected or
give incorrect results anyway:
MMDD HHMM-ZZ (incorrect result)
MMDD HHMMSS-ZZ (incorrect result)
MMDDTHHMM-ZZ (rejected)
MMDDTHHMMSS-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
Re: [PATCH] ISO 8601 basic format and decimal hours, minutes
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?). I'd rather not reject existing valid input unless there's a good reason. Is there one? I didn't see one in the original proposal (admittedly I didn't read it word for word).
Re: [PATCH] ISO 8601 basic format and decimal hours, minutes
Hello Alex, Thank for you putting the time for writing the patch and descriptions in such details. In general: On 2019-02-18 9:00 p.m., Alex Eulenberg wrote: 1. Accept dates in the ISO 8601 basic date and time format. [...]> 2. Accept decimal fractions of time units other than seconds in accordance with ISO 8601. [...] Forms no longer accepted as a result of the patch: [...] input current output output with patch "20180102 00-03" 2018-01-02T03:00+00 + (rejected) "20180102 04-03" 2018-01-02T07:00+00 + (rejected) [...] input current output output with patch "20180102T00-03" (rejected) 2018-01-02T03:00+00 "20180102T04-03" (rejected) 2018-01-02T07:00+00 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?). 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). 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) ). 2. For inputs of form "(YY)YYMMDD'T'hhmm" the current version of parse-datetime interprets the "T" as the single-letter military time zone identifier equivalent to zone offset +0700. This is probably never the intention. Not so, 'T' has special handling code, and in some of the cases is explicitly translated to HOUR(7): https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/parse-datetime.y#n751 doc/parse-datetime.texi | 17 ++-- lib/parse-datetime.y| 193 ++-- tests/test-parse-datetime.c | 115 + 3 files changed, 291 insertions(+), 34 deletions(-) As your contribution is significant (more than 10 lines), a copyright assignment is required before we can review the patch (see https://www.gnu.org/licenses/why-assign.html ). Please complete the following short form and send it to ass...@gnu.org: https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future regards, - assaf
Re: [PATCH] ISO 8601 basic format and decimal hours, minutes
On 2019-02-18 20:00 PST, Alex Eulenberg wrote: 1. Accept dates in the ISO 8601 basic date and time format. This is a format allowing the expression of point in time to the resolution of a second with only alphanumeric characters -- no spaces, no punctuation -- suitable for use in fields that cannot contain spaces, hyphens, or colons. 2. Accept decimal fractions of time units other than seconds in accordance with ISO 8601. Currently only decimal fractions of a second are accepted. With the patch, the decimal separator may be used for the expression of fractions of a minute (in both basic and extended formats) as well as fractions of an hour. Can one of the GNULib maintainers please comment on this submission? --Alex
