Ah, well if it's against POSIX I think we have no choice here but to remove 32 bit time.
On Sun, May 3, 2026, 12:04 PM raiden00pl <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
