From: René Scharfe Date: Tue, 28 Feb 2017 21:31:49 GMT Subject: Re: [PATCH 0/6] Use time_t Message-ID: <6bd6ef64-2749-f17a-aea8-d25b147892c5@web.de> In-Reply-To: Am 28.02.2017 um 21:54 schrieb Johannes Schindelin: > Hi Junio, > > On Tue, 28 Feb 2017, Junio C Hamano wrote: > >> René Scharfe 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`. True, and time_t doesn't even have to be an integer type. But which platforms capable of running git use something else than int32_t or int64_t? René