I'm not so worried about the git date parsing routines (which are fairly
solid) as about the fact that absolutely *tons* of people get rfc2822
wrong.
And we'd never even see it, because gits date-parsing routines are very
forgiving, and allow pretty much anything (and no, I'm not talking about
approxidate(), which really *does* allow anything, I'm talking about the
"strict" date parser).
They allow pretty much any half-way valid date, exactly because people
don't do rfc2822 right anyway (and because they are also meant to work
even if you write the date by hand, like "12:34 2005-06-07").
And *particularly* when it comes to timezones, it just guesses. The whole
daylight savings time thing is just too hard. And if no timezone exists,
it will just take the current one, so things may *seem* like they work,
but then two different people importing the *same* archive in two
different locations will actually get different results!
THAT'S A BAD THING!
It's much better to specify the date so exactly that you simply cannot get
different results with the same input.
Sure, you can still mess up the program that actually generates the data
for gfi, and have bugs like that *there*, but at least they'd have to
think a bit about it.
And the TZ problem is actually less likely if you have a strict TZ format.
For example, when importing from CVS, the natural thing to do is to just
always set TZ to +0000. Which gets you something reliable, and it won't
depend on who did the import.
But hey, especially if it's a flag, and especially if it's *documented*
that the date parsing will depend on the current timezone etc, then maybe
it's all ok. It's certainly convenient to be able to give the date in any
format. It's just very easy to get bugs when you allow any random crud..
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
