Re: git-fast-import

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 6 Feb 2007, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> >
> > I think this is quite error prone, demonstrated by the fact that we 
> > screwed that up ourselves on a few occasions.  I think that the frontend 
> > should be relieved from this by letting it provide the time of change in 
> > a more natural format amongst all possible ones(like RFC2822 for 
> > example) and gfi should simply give it to parse_date().
> 
> This is a really good point.  Its a little bit of work to switch
> to parse_date(); I'll try to get it done tomorrow night.

Actually, I disagree. We've traditionally have had _less_ bugs with the 
pure integer format than we ever had with RFC2822 format.

The original (first seven days) date format inside git objects was 
rfc2822, and it was *horrible*. Not only does it take time to parse, 
people get it constantly wrong, and it's ambiguous what summer-time means 
etc. It's basically impossible to get anything that is totally repeatable 
from it, and you have to be so lax as to effectively accept even buggy 
input. And yes, buggy input exists.

So I would strongly suggest that gfi keeps to the standard git date format 
which is easy to parse, and totally unambiguous. Yes, you can get it 
wrong, but at least then it's very clear *who* gets it wrong: it's 
whatever feeds data to gfi. If gfi accepts a "soft" format, you get into 
all these gray areas of whether you want to be strictly rfc2822 only, or 
whether you actually want to accept stuff that everybody accepts 
(including the git date functions, that try very hard to turn anything 
sensible into a date). And DST. And odd timezone names, etc etc.

Having a hard format, set in stone, and totally unambiguous, is really a 
good thing. It actually ends up resulting in fewer bugs in the end, 
because it just makes sure that everybody is on the same page.

		Linus