On 2024-01-15 18:34, Paul Eggert via tz wrote:
Actually in C a time_t can be floating point. It can even be an enumerated type, or bool.
C 2023 CD has not changed the type specification, and SAS C on IBM mainframes originally used (hex) double with IBM ToD clock epoch 1900-01-01, so they could just tweak the clock value and also get microseconds, then changed to SAS integer date epoch 1960-01-01, before changing to conform to POSIX 1970-01-01. [SAS data still uses JD Julian Date/time, and also integer date with epoch 1960-01-01, in supported range 1582-11-01 to 9999-12-31.]
POSIX formerly allowed time_t to be floating-point, but that was changed in POSIX-2008 as a result of DR 327 <https://www.austingroupbugs.net/view.php?id=327>. In POSIX-2017, time_t can still be bool (!) but in POSIX 202x/D4 the constraints on time_t have changed again: now it must be an integer type that is at least 64 bits wide. (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 use GNU date in scripts as a convenient strftime+ interface to get numeric values for epochs and convert GPS, NTP, Windows time stamps to locale display, the others, Unix, and M/JD: should add IBM and VMS just for historical completeness.] -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry