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 > > > > > > > > > > > > > > >
