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

[Phil Hord <phil.hord@gmail.com>]

> On Thu, Dec 15, 2022 at 8:23 PM Junio C Hamano <gitster@pobox.com> wrote:
> > 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


Do you have any suggestions about how I can better alleviate your
concerns?  I don't think there are real regressions here and I tried
to explain why.