On Thu, Oct 30, 2014 at 05:08:56PM -0400, Dan Johnson wrote: > > The underlying data representation records time as number of seconds > > since epoch (1970-01-01). Theoretically the codepaths that read > > data could consider negative timestamps to represent times before > > the epoch, but in the context of source code control, negative > > values are more likely to be an indication of a bug or a user > > mistake, and I do not think any existing code in Git is prepared to > > pass such a timestamp as a sane value---instead they diagnose a > > failure and die. > > I remember a pretty old thread found some success storing timestamps this way: > http://comments.gmane.org/gmane.comp.version-control.git/152433 A few things have changed since then. Most notably, git is more careful about overflow of "unsigned long" when reading in timestamp values. Of course, we can't do much in the overflow case except assign a sentinel value. But it at least means that overflowing values all end up as "Jan 1 1970" and not whatever random 32-bit wraparound you happen to get. But what _hasn't_ changed is that we still use "unsigned long" internally. The fact that the 1787 date in that thread worked at all is somewhat accidental and due to implicit casts between "unsigned long" and "time_t" working. As noted here (and downthread): http://permalink.gmane.org/gmane.comp.version-control.git/152508 I think it would be a nice project to convert git to consistently use signed 64-bit times internally, and then everything would Just Work going back to the beginning of history. But the demand for such a feature has been low enough that nobody has really dug in and tried the conversion. We do also gain some small amount of efficiency by storing commit timestamps as 32-bit values. However, those should always be "current" times anyway. I think we are really talking about author timestamps here (and of course the underlying time-manipulation functions). -Peff -- 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