On Tue, Feb 28, 2017 at 09:26:23AM -0800, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > I do not just agree, but I think the move to a signed timestamp is a big > > improvement. Git's object format is happy to represent times before > > 1970, but the code is not. I know this has been a pain for people who > > import ancient histories into Git. > > > > It looks from the discussion like the sanest path forward is our own > > signed-64bit timestamp_t. That's unfortunate compared to using the > > standard time_t, but hopefully it would reduce the number of knobs (like > > TIME_T_IS_INT64) in the long run. > > Keeping it unsigned is safer in the short-term. There are some > places that uses 0 as "impossible time" (e.g. somebody tried to > parse a string as time and returns a failure) and these places need > to be found and be replaced with probably the most negative value > that timestamp_t cn represent. Another possible special value we > may use is for "expiring everything" but I think we tend to just use > the timestamp of the present time for that purpose and not UONG_MAX, > so we should be OK there.
Yeah. I think I was the one who invented the "0 is impossible" convention. We can certainly stick with it for now (it's awkward if you really do have an entry on Jan 1 1970, but other than that it's an OK marker). I agree that the most negatively value is probably a saner choice, but we can switch to it after the dust settles. > But we need to cross the bridge to signed timestamp sometime, and I > do not see any reason why that somtime should not be now. Yep. -Peff
