Re: [PATCH 0/6] Use time_t

> Hi Junio,
>
> On Tue, 28 Feb 2017, Junio C Hamano wrote:
>
>> René Scharfe <l.s.r@web.de> writes:
>>
>>> Am 28.02.2017 um 15:28 schrieb Jeff King:
>>>
>>>> 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.
>>>
>>> Glibc will get a way to enable 64-bit time_t on 32-bit platforms
>>> eventually (https://sourceware.org/glibc/wiki/Y2038ProofnessDesign).
>>> Can platforms that won't provide a 64-bit time_t by 2038 be actually
>>> used at that point?  How would we get time information on them?  How
>>> would a custom timestamp_t help us?
>>
>> That's a sensible "wait, let's step back a bit".  I take it that you are
>> saying "time_t is just fine", and I am inclined to agree.
>>
>> Right now, they may be able to have future timestamps ranging to
>> year 2100 and switching to time_t would limit their ability to
>> express future time to 2038 but they would be able to express
>> timestamp in the past to cover most of 20th century.  Given that
>> these 32-bit time_t software platforms will die off before year 2038
>> (either by underlying hardware getting obsolete, or software updated
>> to handle 64-bit time_t), the (temporary) loss of 2038-2100 range
>> would not be too big a deal to warrant additional complexity.
>
> You seem to assume that time_t is required to be signed. But from my
> understanding that is only guaranteed by POSIX, not by ISO C.
>
> We may very well buy ourselves a ton of trouble if we decide to switch to
> `time_t` rather than to `int64_t`.