[tz] strftime %s
Brian.Inglis at SystematicSW.ab.ca
Brian.Inglis at SystematicSW.ab.ca
Mon Jan 22 04:36:25 UTC 2024
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 at 999999999999999 +%Y
31690708
perhaps they wanted to ensure they could support up to:
$ date -d at 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
More information about the tz
mailing list