Re: [PATCH 0/6] Use time_t

From: Jeff King <peff@peff.net>
Date: Feb 28, 2017, 20:01 UTC
Message-ID: <20170228200145.ymbqmxwrbbrwagks@sigill.intra.peff.net>
In-Reply-To: <xmqqvarukz0g.fsf@gitster.mtv.corp.google.com>

On Tue, Feb 28, 2017 at 09:26:23AM -0800, Junio C Hamano wrote:

Show 20 quoted lines

> Jeff King <peff@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