Re: [PATCH] date.c: allow ISO 8601 reduced precision times

From: Phil Hord <phil.hord@gmail.com>
Date: Dec 16, 2022, 18:38 UTC
Message-ID: <CABURp0pWwfWO3msZ4U=_i3zkEDOq6+CUVT9Tb7KCjeBRK34Miw@mail.gmail.com>
In-Reply-To: <xmqq359gnfhe.fsf@gitster.g>

On Thu, Dec 15, 2022 at 8:23 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

>
> Phil Hord <phil.hord@gmail.com> writes:
>
> > From: Phil Hord <phil.hord@gmail.com>
> >
> > ISO 8601 permits "reduced precision" time representations to omit the
> > seconds value or both the minutes and the seconds values.  The
> > abbreviate times could look like 17:45 or 1745 to omit the seconds,
> > or simply as 17 to omit both the minutes and the seconds.
> >
> > parse_date_basic accepts the 17:45 format but it rejects the other two.
> > Fix it to accept 4-digit and 2-digit time values when they follow a
> > recognized date but no time has yet been parsed.
>
> I worry a bit that this may conflict with other approxidate
> heuristics.

I share your concern. I tried to make the ISO matching code very specific to the case where we have already matched a date, we have not yet matched a time value, and we see a lone 2-digit or 4-digit number show up.

Show 8 quoted lines

> > $ test-tool date approxidate 2022-12-13T23:00 2022-12-13T2300 2022-12-13T23
> > 2022-12-13T23:00 -> 2022-12-14 07:00:00 +0000
> > 2022-12-13T2300 -> 2022-12-14 07:00:00 +0000
> > 2022-12-13T23 -> 2022-12-14 07:00:00 +0000
>
> All of these may be obvious improvements, but the thing is that
> there is nothing in the approxidate parsing code that insists on the
> presence of "T" to loosen the rule only for ISO-8601 case.

I considered making the T an explicit marker, but it didn't seem necessary here. But the looseness of approxidate with regard to spaces is worrisome. That's why I added the date/no-time constraints.

> For example, with only 6 digits, do we still recognise our internal
> timestamp format (i.e. seconds since epoch) without the
> disambiguating '@' prefix?

I don't grok your example. This change should not affect the interpretation of any 6-digit number.

Oh, do you mean if there was _no_ delimiter before the time field? Like 2022-12-132300? My change will not recognize this format, and I believe it was explicitly rejected by ISO-8601-1:2019.

approxidate seems not to recognize fewer than 9 digits as an epoch number, even with the @ prefix. But this is not because of my change.

test-tool date approxidate 123456789 12345678 123456789 -> 1973-11-29 21:33:09 +0000 12345678 -> 2022-12-16 18:34:02 +0000

test-tool date approxidate @123456789 @12345678 @123456789 -> 1973-11-29 21:33:09 +0000 @12345678 -> 2022-12-16 18:36:35 +0000

test-tool date parse 123456789 12345678 123456789 -> 1973-11-29 13:33:09 -0800 12345678 -> bad

test-tool date parse @123456789 @12345678 @123456789 -> 1973-11-29 13:33:09 -0800 @12345678 -> bad