Hi,
I just noticed GCC_ARM and ARMC6 in Mbed Studio give have different size of time_t. GCC_ARM uses 8 byte for time_t while ARMC6 uses 4 byte. Does that mean if we GCC_ARM we don’t need to worrry about the 2038 problem no more?
This was checked on Mbed-OS-5.15.6.
Hello Li,
In GCC_ARM the time_t data type is defined as __int_least64_t and this can handle the time roughly till1970 + (2^63-1)/60/60/24/365 = 292471210647. So we shouldn’t worry about the 2038 problem. I don’t use the ARMC6 chain so I’m not sure, however, if the time_t is defined there as unsigned 4-byte data type (i.e. uint_32) rather than a signed one (i.e. int_32) then it can handle the time roughly till 1970 + 2^32/60/60/24/365 = 2106.
Hi Mr. Zoltan,
Thanks for the reply. I assume there are some other parts that need to be cleared to be 2038-problem free. such as time(), mktime() and other time related functions, or even device specific driver/abstract layer. My concern is if those parts are not ready, we can just force 4 byte time_t in GCC_ARM to save a few bytes here or there.
You are right. There are also other problems with time. For example, leap years. Fortunately, MBED and its partners are trying to handle those too:
mbed-os/platform/include/platform/mbed_mktime.h
mbed-os/targets/TARGET_STM/rtc_api.c