2020-12-15 05:20 PM
Cannot set a time greater than 2038, whether in the console or the c program
2020-12-15 10:01 PM
Hi,
not a solution but additional information:
This is a known bug named the 'Year 2038 problem' due to using a 32Bit signed Integer to count the seconds since 1 January 1970. There is even a Wikipedia article for it: https://en.wikipedia.org/wiki/Year_2038_problem
It should be solved by serveral kernel patches (see here: https://lkml.org/lkml/2020/1/29/355?anz=web) which I don't know if they are backported to the ST provided kernel (never looked at it, maybe a ST employee / other community member knows it, a quick git log --grep y2038 showed some related commits). Also this post might help you: https://unix.stackexchange.com/questions/396373/bash-date-working-around-the-2038-bug-on-32bit-linux-system
2021-02-28 10:27 PM
Does ST have specific instructions or patching plans for this issue, Our development underway and nearing completion, Considering that the device will continue to be sold and maintained for more than year 2038, hope to solve this problem before going on market
2021-03-01 02:37 AM
The hardware seem obvious to be capable of working after 2038 as it count second/minutes/hourds/days/month/ years. Check and rewrite the software. Try to set the date direct in the registers.
2021-03-01 08:44 PM
I think this is not a good way. In the Linux ecosystem, there are a large number of middlewares that use the libc interface instead of registers to get the system time. This is neither a standard implementation, nor the ability of small organizations to modify so many software, so I still hope that ST can solve the problem. I found that this problem is common in 32-bit systems. The kernel seems to have completely fixed this problem after 5.6. I don’t know if ST has plans to patch the current version.