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))
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
