On Thu, Nov 7, 2024 at 4:38 PM Gregory Nutt <spudan...@gmail.com> wrote: > > 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.
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)? :-) This provides backward compatibility, easy configuration versatility / fine tuning, and we may change the default when new POSIX standard is ratified? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
