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

From: Junio C Hamano <[email-masked]>
Date: Fri, 16 Dec 2022 13:23:57 +0900

Phil Hord <[email-masked]> writes:

> From: Phil Hord <[email-masked]>
>
> 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.

> $ 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.

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