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