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. > 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. Thanks.