Re: [ANNOUNCE] Git v2.9.1

[Jeff King <peff@peff.net>]

On Tue, Jul 12, 2016 at 07:34:14AM -0700, Junio C Hamano wrote:

> > Git's source code assumes that unsigned long is at least as precise as
> > time_t. Well, Git's source code is wrong.
> > ...
> 
> That is correct.  As people mentioned downthread already, "unsigned
> long" has two problems, it may not be wide enough, and it cannot
> represent time before the epoch.
> 
> But moving the internal time representation used in various fields
> like commit->date to time_t is likely to be a wrong thing to do,
> because the first problem with "unsigned long", i.e. "may not be
> wide enough", is not limited to "not wide enough to hold time_t".
> It also includes "it may not be wide enough to hold time somebody
> else recorded in existing objects".

But that's a problem no matter what size we choose. The ascii format in
the commit objects is arbitrary-length, so somebody can always overflow
it. So even with intmax_t we have to clamp it to a sentinel value at
some point. IMHO we are better off to do so at parse time, and then have
consistent sizes through the rest of the code base, without worrying
about juggling intmax_t to time_t truncation in multiple places.

IOW, I think we probably interact with the system time libraries more
often than we parse (and it's easy to wrap the parsing in a function,
but there are a lot of system time functions).

-Peff