From: René Scharfe Date: Tue, 28 Feb 2017 16:38:37 GMT Subject: Re: [PATCH 0/6] Use time_t Message-ID: In-Reply-To: <20170228142802.hu5esthnqdsgc2po@sigill.intra.peff.net> Am 28.02.2017 um 15:28 schrieb Jeff King: > On Mon, Feb 27, 2017 at 10:30:20PM +0100, Johannes Schindelin wrote: > >> One notable fallout of this patch series is that on 64-bit Linux (and >> other platforms where `unsigned long` is 64-bit), we now limit the range >> of dates to LONG_MAX (i.e. the *signed* maximum value). This needs to be >> done as `time_t` can be signed (and indeed is at least on my Ubuntu >> setup). >> >> Obviously, I think that we can live with that, and I hope that all >> interested parties agree. > > I do not just agree, but I think the move to a signed timestamp is a big > improvement. Git's object format is happy to represent times before > 1970, but the code is not. I know this has been a pain for people who > import ancient histories into Git. > > 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? Regarding the need for knobs: We could let the compiler chose between strtoll() and strtol() based on the size of time_t, in an inline function. The maximum value can be calculated using its size as well. And we could use PRIdMAX and cast to intmax_t for printing. René