On Thu, Dec 15, 2022 at 8:23 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Phil Hord <phil.hord@xxxxxxxxx> writes: > > > From: Phil Hord <phil.hord@xxxxxxxxx> > > > > 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. > > $ 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
