Further 'approxidate' improvements
commit36e4986f26d18defa51fd7af60ec7e7a98337902
authorLinus Torvalds <torvalds@linux-foundation.org>
Sun, 23 Aug 2009 01:11:44 +0000 (22 18:11 -0700)
committerJunio C Hamano <gitster@pobox.com>
Sun, 23 Aug 2009 01:51:06 +0000 (22 18:51 -0700)
tree19d6fe801232da5c46522af7e0c478e1c9cb7dac
parent9029055207443c28ca65a705d1a1b96cce3995fd
Further 'approxidate' improvements

The previous patch to improve approxidate got us to the point that a lot
of the remaining annoyances were due to the 'strict' date handling running
first, and deciding that it got a good enough date that the approximate
date routines were never even invoked.

For example, using a date string like

6AM, June 7, 2009

the strict date logic would be perfectly happy with the "June 7, 2009"
part, and ignore the 6AM part that it didn't understand - resulting in the
information getting dropped on the floor:

6AM, June 7, 2009 -> Sat Jun 6 00:00:00 2009

and the date being calculated as if it was midnight, and the '6AM' having
confused the date routines into thinking about '6 June' rather than 'June
7' at 6AM (ie notice how the _day_ was wrong due to this, not just the
time).

So this makes the strict date routines a bit stricter, and requires that
not just the date, but also the time, has actually been parsed. With that
fix, and trivial extension of the approxidate routines, git now properly
parses the date as

6AM, June 7, 2009 -> Sun Jun  7 06:00:00 2009

without dropping the fuzzy time ("6AM" or "noon" or any of the other
non-strict time formats) on the floor.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
date.c