On 11/7/2024 12:57 AM, Takashi Yamamoto wrote:
my suggestion is to keep our time_t unsigned for now and revisit
when/if we solve the issues of targets w/o 64-bit integers.
(either by improving the toolchains, or stop supporting those targets,
or inventing a way to workaround the year 2038 issue.)
That is a good decision too. Remember that with using uint32_t as
NuttX always has, there is no year 2038 issue. That issue would only
occur if we go to int32_t which has one bit less of range.
The best reasons for leaving time_t as it is currently defined are:
* We don't have a year 2038 that needs to be solved (unless we
introduce it)
* The POSIX committee is currently working on the new time definition
to avoid the year 2038 problem. And definition we invent ourselves
now will need to be changed again when the newer POSIX standard is
released.
I have seen discussions of increasing the width of time_t AND adding
higher resolution timing (milleseconds or microseconds instead of the
seconds since the epoch).
Changing the type of time_t will likely require re-work of many of the
internal time computations, especially if the time unit changes.
