On 11/7/2024 10:59 AM, Tomek CEDRO wrote:
Does adding kconfig's configurable time_t with uint32_t default
(as-is) with option to change int32_t and int64_t sounds good? Should
we use manual selection only or auto-detection (i.e. int64_t on 64-bit
archs)? :-)
==== /Initial Response /====
Not really. The POSIX specification for time_t is still under work.
Just changing the type to int64_t is one likely result amongst others.
I would not invest the effort in the timing calculations for an
arbitrary non-standard solution. I would wait for the specification to
be released and not waste effort guessing what the standard will be.
"In a future version of this volume of POSIX.1-2017, *time_t* is
likely to be required to be capable of representing times far in the
future. Whether this will be mandated as a 64-bit type or a
requirement that a specific date in the future be representable (for
example, 10000 AD) is not yet determined. Systems purchased after
the approval of this volume of POSIX.1-2017 should be evaluated to
determine whether their lifetime will extend past 2038."
https://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html
If you are a gambling man and don't mind the risk of re-working time_t
related logic, then I would bet on the type being int64_t as you are
advocating. What will be the units of time? Still 1 sec? Probably
not. Perhaps time_t will become a structure? We don't really know.
int64_t is not a bad bet but not substantiated by specification yet either.
This provides backward compatibility, easy configuration versatility /
fine tuning, and we may change the default when new POSIX standard is
ratified? :-)
Which might be a big job and might make all of that non-standard,
unspecified implementation throw-away code.If someone wants to go
through that effort and verify/fix all of the timing calculation
functions as needed to support int54_t time_t, I would not oppose that.
==== /LATER /====
*/Never mind/*. POSIX 2024 has just been released and time_t is now
required to be 64-bits. Lots and lots of other changes as well.
* https://sortix.org/blog/posix-2024/
The 2038 32-bit |time_t| apocalypse has been canceled to contain
SCP-8601 <https://scp-wiki.wikidot.com/scp-8601>.
*
https://www.reddit.com/r/C_Programming/comments/1e2ac63/new_features_for_c_in_posix_2024/?rdt=50686
|time_t| is now required to be 64-bit. Farewell year 2038 problem.
I have seen on these POSIX summaries and would really like to see the
language of the actual spec. At any rate, will a solid basis in
specifications. I now agree with you. time_t must 64 bits on all
platforms and with all tools.
