On Tue, 6 Feb 2007, Shawn O. Pearce wrote: > Nicolas Pitre <nico@xxxxxxx> 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 - 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