Hi Junio, On Tue, 28 Feb 2017, Junio C Hamano wrote: > René Scharfe <l.s.r@xxxxxx> 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`. Ciao, Johannes