[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