On 2024-01-21 20:36, Brian.Inglis--- via tz wrote:
(Why 64 bits? Surely 60 bits would have been enough for real-world timestamps....)
In decimal integers, that only supports up to:
$ date -d@999999999999999 +%Y 31690708
perhaps they wanted to ensure they could support up to:
$ date -d@9999999999999999 +%Y 316889355
;^p
I'm not sure where those decimal integers came from. A 60-bit time_t, if signed, would support a time_t range of about -5.8e+17 .. 5.8e+17 seconds. The universe is about 13.8e+9 years or about 4.4e+17 seconds old, so a 60-bit signed time_t would cover the known universe's history so far, with a goodly amount of room for the future. Perhaps the POSIX standardizers were thinking that 18 billion years of future timestamps aren't enough, and that some apps need support for at least 292 billion years into the future. But what applications were they thinking of? Also on typical platforms where int is 32 bits, localtime stops working for time_t values greater than around 6.8e+16, so even 60-bit time_t is overkill for today's platforms. Also, the earth's rotation will become incompatible with POSIX long before 60-bit time_t rolls over....