On Tue, Sep 10, 2019 at 08:19:49PM +0300, Diomidis Spinellis wrote: > > > - Can you think of any non-obvious issues (e.g. backward compatibility, > > > switch to the Gregorian calendar) I should be aware of? > > > > The big question is: what will existing implementations do with a commit > > object that contains a negative timestamp? > > Negative timestamps can already be created, because some Git libraries can > create such objects, and one can also create them by hand; see http://git.661346.n2.nabble.com/Back-dating-commits-way-back-for-constitution-git-tp5365303p5367657.html > > Consequently, I don't think that worrying about how existing clients will > handle such timestamps should be a big issue, as long as we don't break the > handling of modern dates. Yes, it's easy to create lots of things with git-hash-object, but that doesn't mean we should be encouraging people (yet). :) That said, I think the handling here is pretty favorable: if you're not using very old timestamps, you won't see any problem. And if you do use them, the old presentation code handles it pretty well. We'd probably want to warn people that older versions of Git may complain when fsck-ing. > > Here's how far I got working on this yesterday. It's quite messy, but > > seems to work at least for basic tests like: > > Amazing! Given that you have made significant progress, I think it's best > to leave it to you to complete it, right? I was afraid you'd say that. :) I did spend a few more minutes looking into it after the last email. There's a rabbit hole of handling timestamp parsing where many cases are not actually checking appropriately for errors. So I think we'd want to deal with those sites, too, while we're touching parse_timestamp(). It's not clear to me yet how deep the rabbit hole of little fixes goes (or how deep we need to go for this particular feature). So I hope to return to it when I have time, but if you or anybody else would like to poke at it in the meantime, be my guest. -Peff
