Re: [ANNOUNCE] Git v2.9.1
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 12, 2016, 15:25 UTC
- 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:
Show 9 quoted lines
>> >> 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.