Jeff King <peff@xxxxxxxx> writes: > But I wonder if the new patch breaks the example from that commit > message, which does work now: > > [current version; the 17 attaches to "days ago"] > $ t/helper/test-tool date approxidate 12:43:50.17.days.ago > 12:43:50.17.days.ago -> 2020-03-29 16:43:50 +0000 > > It looks like the answer is yes: > > [with patch 1/2 applied; now it's a fractional second] > $ t/helper/test-tool date approxidate 12:43:50.17.days.ago > 12:43:50.17.days.ago -> 2020-04-15 16:43:50 +0000 > > TBH I'm not sure how big a deal it is. The input is rather ambiguous for > a strict left-to-right parser, and I'm not sure this case is worth doing > more look-ahead parsing. But it's worth making a conscious decision > about it. True. I do agree that this would qualify as a regression, but I do not think we are breaking an important use case here. > One alternative would be to restrict the fractional second handling only > to the parse_date_basic(), which is quite a bit stricter. It shares > match_digit() with approxidate(), so we'd probably have to pass in an > extra flag to match_digit() to change the rules. It also means that: > > 2020-04-14T12:43:50.17 > > would parse a fractional second, but: > > yesterday at 12:43:50.17 > > wouldn't. That sounds less useful. Somehow "yesterday at 12.43:50.17" looks a lot more plausible real-user input that we would want to support better than "12:43:50.17.day.ago". > I do agree that year bounds are a questionable restriction. Right now > Git's date code can only handle dates between 1970 and 2099, but it > would be nice to change that. Sure. In both directions.
