Will the 2038 years problem be happned on IoT reference of FreeRTOS?

Libraries
1

There is the LTS of FreeRTOS libs on the github of FreeRTOS.
I would like to know whether the libs of LTS are corresponding the 2038 years of UTC problem or not.

Is anyone know the libs and FreeRTOS are already solved this problem or not?

The 2038 years problem.

2

For the kernel, time starts when you turn the device running FreeRTOS on, so there won’t be any issues for time measured using the tick count.

3

@Kei.Kashi The FreeRTOS kernel does not provide time / date related functions. These are provided by your platform’s c standard library. This means that your c standard library would need to be “year 2038” compatible.

A quick and easy check is to see how large the time_t is for your system. If time_t is a 64-bit type, you likely have little to worry about. However, If time_t a 32-bit type, it warrants further investigation.

4

Hi, PaulB-AWS, rtel

Thank you for your prompt answer. I appreciate it.
I got the Kernel of FreeRTOS, but I also would like to know whether LTS libraries of FreeRTOS have the 2038 years problem or not.

FreeRTOS-LTS :

Below list is my survey if they are applicable or not.

Is my understanding correct?

  • Items
    • FreeRTOS-Cellular-Interface : Not applicable
    • FreeRTOS-Kernel : Not applicable(Doen’t provide any UTC time)
    • FreeRTOS-Plus-TCP : Not applicable
    • backoffAlgorithm : Not applicable
    • coreHTTP : Not applicable
    • coreJSON : Not applicable
    • coreMQTT : Not applicable
    • corePKCS11 : Not applicable
    • coreSNTP : Applicable(Some code using UTC time)
5

Yes, you are correct. The 2038 problem is applicable to coreSNTP as some code does use UTC time. We can look into addressing this in a future release of the library. Thank you again for the post!

1 Like