Re: Date parsing
- From
Linus Torvalds <torvalds@linux-foundation.org>
- Date
- Jun 21, 2008, 22:28 UTC
- Message-ID
- <alpine.LFD.1.10.0806211507370.2926@woody.linux-foundation.org>
- In-Reply-To
- <20080621215240.GD15111@leksak.fem-net>
On Sat, 21 Jun 2008, Stephan Beyer wrote:
Show 21 quoted lines
> > 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))