Re: [BUG] minor: wrong handling of GIT_AUTHOR_DATE

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Aug 17, 2008, 04:37 UTC
Message-ID: <alpine.LFD.1.10.0808162128400.3324@nehalem.linux-foundation.org>
In-Reply-To: <alpine.LFD.1.10.0808162054050.3324@nehalem.linux-foundation.org>

On Sat, 16 Aug 2008, Linus Torvalds wrote:

Show 18 quoted lines

> 
> The rules are:
> 
>  - valid days of month/mday are always single or double digits.
> 
>  - valid years are either two or four digits
> 
>    No, we don't support the year 600 _anyway_, since our encoding is based 
>    on the UNIX epoch, and the day we worry about the year 10,000 is far 
>    away and we can raise the limit to five digits when we get closer.
> 
>  - Other numbers (eg "600 days ago") can have any number of digits, but 
>    they cannot start with a zero. Again, the only exception is for 
>    two-digit numbers, since that is fairly common for dates ("Dec 01" is 
>    not unheard of)
> 
> So that means that any milli- or micro-second would be thrown out just 
> because the number of digits shows that it cannot be an interesting date.

I should explain that nonsensical statement a bit.

A milli- or micro-second can obviously be a perfectly fine number according to the rules above, as long as it doesn't start with a '0'. So if we have

	12:34:56.123

then that '123' gets parsed as a number, and we remember it. But because it's bigger than 31, we'll never use it as such _unless_ there is something after it to trigger that use.

So you can say "12:34:56.123.days.ago", and because of the "days", that 123 will actually be meaninful now.

But the problem with "12.34.56.001" was that we used to remember the "001" as a number, and because we could see no other use for it we then assumed that it meant the day of the month.

Of course, we *should* do that only if we have seen a month-name too, but we don't currently track that, so.. Adding that as a further sanity test would be good, but it would require us to have some extra "flags" field. Maybe we should have a

	#define SEEN_MONTH	1
	#define SEEN_YEAR	2
	#define SEEN_DAY	4
	#define SEEN_TIME	8
	...

	struct extended_tm {
		unsigned long seen;
		unsigned long number;
		struct tm tm;
	}

and pass *that* around instead of passing "struct tm *" and "unsigned long *num" around. That would be good. Then we could do

	if (tm->number && tm->number < 32 &&
	    (tm->seen & SEEN_MONTH) && !(tm->seen & SEEN_DAY))
		tm->tm.tm_mday = tm->number;

there instead, which would protect us from other numbers just being seen as days instead.

Anybody? I'm not going to bother.

			Linus