Re: Date parsing

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sat, 21 Jun 2008, Stephan Beyer wrote:
> 
> Today I've been playing around with approxidate(), too, and I think I
> found some bug in date parsing. I let copy&paste speak...
> 
> Correct:
> 
> $ ./test-date "2008-07-01 23:59:59 +0200"
> 2008-07-01 23:59:59 +0200 -> 1214949599 +0200 -> Tue Jul  1 23:59:59 2008
> 2008-07-01 23:59:59 +0200 -> Tue Jul  1 23:59:59 2008
> 
> And even:
> 
> $ ./test-date "2008-07-01 24:00:00 +0200"
> 2008-07-01 24:00:00 +0200 -> 1214949600 +0200 -> Wed Jul  2 00:00:00 2008
> 2008-07-01 24:00:00 +0200 -> Wed Jul  2 00:00:00 2008
> 
> But then there's a jump in time:
> 
> $ ./test-date "2008-07-02 00:00:00 +0200"
> 2008-07-02 00:00:00 +0200 -> 1202335200 +0200 -> Wed Feb  6 23:00:00 2008
> 2008-07-02 00:00:00 +0200 -> Wed Feb  6 23:00:00 2008

Heh.

What you're seeing is that approxidate() does not like dates in the 
future. You're hitting this case:

                /* Be it commit time or author time, it does not make
                 * sense to specify timestamp way into the future.  Make
                 * sure it is not later than ten days from now...
                 */
                if (now + 10*24*3600 < specified)
                        return 0;

so approxidate() refuses to think that "2008-07-02" is a valid date in 
July, because it is more than ten days in the future. So it decides that 
if somebody tried to feed it a date like that, it must be the seventh of 
February instead of July.

So the refusal to look at future dates is part of trying to disambiguate 
the "dd.mm" form from the "mm.dd" form, where it will decide that if it's 
far in the future (where "far" is 10 days), it cannot be right.

Remember: the git date handling was _not_ meant to be a generic date 
library. It is very much meant to be a *git* date library. This is why you 
can say things like "7 days ago", and it will return something sane, but 
if you say "7 days from now", it will still think you're talking about 
seven days ago - it simply doesn't have the concept of "future date".

That said, I think that in this case the thing just doesn't make sense. 
For the specific case of iso time format, we perhaps shouldn't even try to 
refuse future dates. Does anybody use the insane yyyy-dd-mm format? 

To avoid the future check, you could try something like the appended.

Of course, the whole parser was really designed to parse email dates from 
the beginning, and rfc2822 actually ends up being totally unambiguous and 
also won't ever hit the "refuse future" case.

So I was wrong. Rather than using the European ISO format (yyyy-mm-dd), 
the really safest format is the "English month name spelled out" format, 
ie

	./test-date "12 Jul 2010"

parses correctly, but

	./test-date 2010-07-12

does not, because the latter is found suspect due to being in the future.

		Linus

---
 date.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/date.c b/date.c
index 1a4eb87..870419a 100644
--- a/date.c
+++ b/date.c
@@ -374,7 +374,7 @@ static int match_multi_number(unsigned long num, char c, const char *date, char
 
 		if (num > 70) {
 			/* yyyy-mm-dd? */
-			if (is_date(num, num2, num3, refuse_future, now, tm))
+			if (is_date(num, num2, num3, NULL, now, tm))
 				break;
 			/* yyyy-dd-mm? */
 			if (is_date(num, num3, num2, refuse_future, now, tm))