From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 12 Jul 2016 15:25:51 GMT
Subject: Re: [ANNOUNCE] Git v2.9.1
Message-ID: <CAPc5daWcb5bfgsxMP0vCrQ7gBdeYBgefzPNHztaaCKzqbCv2aQ@mail.gmail.com>
In-Reply-To: <20160712151630.GE613@sigill.intra.peff.net>

On Tue, Jul 12, 2016 at 8:16 AM, Jeff King <peff@peff.net> wrote:
>>
>> 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.

Yes, if somebody's time_t is larger than my intmax_t, the problem
cannot be solved for me, if that timestamp is too far in the future or
in the past.

But that is not the problem I am pointing out. I heard earlier in the
thread that time_t on one system was 32-bit (was it Linux?) but I think
they have "long long". Choosing time_t is strictly inferior choice when
we already know that a platform with not-wide-enough time_t need to
be supported, and a type that is wider than that is available.

I was envisioning that we would have typedef <sometime> gittime_t
with conversion helpers between it and time_t that allow us to do some
range checks while at it.