Re: [PATCH 0/6] Use time_t

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 28, 2017, 17:26 UTC
Message-ID: <xmqqvarukz0g.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170228142802.hu5esthnqdsgc2po@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 9 quoted lines

> 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.

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.