On Tue, 6 Feb 2007, Shawn O. Pearce wrote: > > If the source is only supplying RFC2822 date format and is reliable > in its formatting of such, having gfi parse that rather than > the frontend is probably more reliable. (Git already has a well > tested date parsing routine.) 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html