If I did the calculations correctly, the time in seconds from Jan 1, 1970 to the present time has already used the top byte of a uint32.
________________________________ From: [email protected] <[email protected]> Sent: Monday, May 4, 2026 7:37 AM To: [email protected] <[email protected]> Subject: Re: [DISCUSS] Removal of CONFIG_SYSTEM_TIME64 and make time_t 64-bit by default On 2026-05-04 15:19, raiden00pl wrote: > " ## Strict POSIX compliance" is the first point in the INVIOLABLES.md, > so I assume this is the main purpose of NuttX's existence. The main > priority > is POSIX, everything else is an addition - that's how I understand it. The thing is - in my opinion - that interpretation of "strict POSIX compliance" is application-dependent. Let's have an application that doesn't know real (calendar) time (so it always starts in year 1970) and never runs for more than a day or few days at most. Such an application will always have top four bytes of time_t and clock_t values set to zero. Under such conditions, the compiler (optimizer) is entitled to simply remove any calculations involving those bytes and even not allocate space for them - that's with clock_t/time_t defined as uint64_t. The compiler obviously cannot know how the application will be used - but the application author does and can state that in the configuration. "Use uint32_t for time_t/clock_t" then simply becomes "Size of time_t/clock_t is 64 bits but I declare that top 4 bytes of that are always zero". Using uint32_t is simply a way to tell the compiler that it should skip the top 4 bytes of uint64_t. Then you have compliant time_t/clock_t AND do not waste program memory/RAM. Yes, it is at the cost of some #ifdefs
