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