The new POSIX standard explicitly states that time must be 64 bits. While disabling signals and other optimizations in NuttX can be considered an acceptable optimization for embedded systems, the 32-bit time doesn't seem like an optimization, but rather a direct violation of the standard. So I disagree here. time_t as 64-bit is not a suggestion, it is REQUIREMENT. Leaving 32-bit time is a direct departure from POSIX.
Don't try to please everyone, NuttX is supposed to be POSIX, not a system for every possible purpose and every possible use case. niedz., 3 maj 2026 o 16:44 Matteo Golin <[email protected]> napisał(a): > That seems like a reasonable approach! > > On Sun, May 3, 2026, 10:13 AM Alan C. Assis <[email protected]> wrote: > > > Exactly, but the point is: if we can fix it now, why to merge a PR and > > later spend time adding it back to Kconfig ? > > > > See the "signal" history as an example, it was removed some years ago, > and > > then we spent a lot of time and energy discussing how to return with it > (at > > least partial signal disable). > > > > I think just changing the Kconfig to CONFIG_SYSTEM_TIME64 default Y will > > fix the issue since all boards will have it be default and only someone > > willing to run NuttX on some small MCU or retro hardware can disable it. > > > > This way is better than removing the support to TIME 32-bit all together. > > > > BR, > > > > Alan > > > > On Sun, May 3, 2026 at 10:47 AM Matteo Golin <[email protected]> > > wrote: > > > > > Size could be a valid concern. We can always add the ability to go back > > to > > > 32 bit time in Kconfig. Does this have any concerns with violating > POSIX? > > > I'd imagine not, given that it used to be 32 bit. > > > > > > On Sun, May 3, 2026, 9:33 AM Alan C. Assis <[email protected]> wrote: > > > > > > > Hi Matheusz, > > > > > > > > Thank you , so probably I forgot about this discussion. Sorry Xiang > for > > > > raising this Discussion, but I thought it wasn't discussed before. > > > > > > > > Anyway I think we need to see how much it will increase in Flash/RAM. > > > > > > > > If it increases "a lot" (more than 700 bytes), maybe we should keep > > this > > > > config and just make it default Y, because people could use NuttX on > > > small > > > > microcontrollers that could be left behind with this change. > > > > > > > > This is part of the "The Inviolable Principles of NuttX: All Users > > > Matter", > > > > especially that part: > > > > - > > > > > > > > *Hobbyists are valued users of the OS including retro computing > > hobbyists > > > > and DIY “Maker” hobbyists.* > > > > In the past we already did drastic modifications that increased NuttX > > > size > > > > and now we are trying to figure out how to fix what we did. > > > > > > > > BR, > > > > > > > > Alan > > > > > > > > On Sun, May 3, 2026 at 9:17 AM raiden00pl <[email protected]> > > wrote: > > > > > > > > > 32 bit time is not compatible with the latest POSIX and it was > > already > > > > > agreed that this change would be included in release 13 in one of > > > > > the previous discussions on this topic. We were just waiting for > > > release > > > > > 13. > > > > > > > > > > niedz., 3 maj 2026 o 13:52 Alan C. Assis <[email protected]> > > > napisał(a): > > > > > > > > > > > Hi Everyone, > > > > > > I want to bring this PR to your attention: > > > > > > https://github.com/apache/nuttx/pull/18840 > > > > > > > > > > > > I have some concerns like those added to my Change Request there. > > > > > > > > > > > > I think broad modifications like this need to be discussed with > our > > > > > > community. > > > > > > > > > > > > I'm not against this PR, it will avoid the 2038 Unix Epoch BUG, > but > > > it > > > > is > > > > > > important to know first the impact of this commit to small > > > > > > microcontrollers. > > > > > > > > > > > > Unfortunately we don't have how many bytes this PR will > add/remove > > > > > to/from > > > > > > Flash and RAM. > > > > > > > > > > > > Also we discussed many times that all PRs need to include valid > > > > testing, > > > > > > just "checkpatch.sh -f" is not a real test, it doesn't guarantee > > that > > > > the > > > > > > PR will pass in the CI. > > > > > > > > > > > > In cases like this where a PR modifies many boards and MCUs, a > good > > > > idea > > > > > it > > > > > > to test it on your own github account first, before submitting > the > > > PR, > > > > as > > > > > > explained here: https://github.com/apache/nuttx/issues/18568 > > > > > > > > > > > > This is not a criticism of the author, that is my friend, but it > is > > > > > > important that we improve our process. Seems like we are still > > > messing > > > > > with > > > > > > basic things. > > > > > > > > > > > > BR, > > > > > > > > > > > > Alan > > > > > > > > > > > > > > > > > > > > >
