How to handle year 2038 bug with ESP32/PIO?

1

Hi – beginner here, on ESP32 with vscode/pio, esp32 platform / arduino framework. I am using time_t all over my code for temp/humidity logging and other things, but I have read that it will fail in 2038.

I can’t seem to find much info on how to handle this situation; I found this post suggesting some build flags but they had no effect when I added them (on a whim) in platformio.ini.

I found another post that suggests that most libraries now use an unsigned long to represent time, but when I F12 through the type definitions it looks like it’s defined as long; in /home/me/.platformio/packages/toolchain-xtensa-esp32/xtensa-esp32-elf/sys-include/sys/_timeval.h:

#if !defined(__time_t_defined) && !defined(_TIME_T_DECLARED)
typedef _TIME_T_ time_t;
#define __time_t_defined
#define _TIME_T_DECLARED
#endif

in /home/me/.platformio/packages/toolchain-xtensa-esp32/xtensa-esp32-elf/sys-include/sys/_types.h:

#if defined(_USE_LONG_TIME_T) || __LONG_MAX__ > 0x7fffffffL
#define _TIME_T_ long
#else
#define _TIME_T_ __int_least64_t
#endif

I admit that while I understand the conceptual issue (signed 32bit time_t can’t represent that many seconds since the epoch) the architectural issue (which abstracted library layer/library/compiler/whatever is relevant, how that can be changed, and how those changes can be effected in the context of PIO/vscode) is well over my head.

Is there anything I can do to make my embedded device work past 2038? Or is it in fact using unsigned long already so I don’t need to worry until 2106? Or is this just a deficiency in the underlying architecture and there’s nothing I can realistically do as a beginner until those libraries are updated?

(Note: yes, I know 2038 is a long way away, but I’d like my device to be operating well past then, hence the question. :slight_smile: )

Thanks!

2

First of all: Have you created an ESP32 program that does Serial.println(sizeof(time_t));? Does that return 4 or 8?

3

Thanks – yes I ran code from the post linked above and it shows 4 for time_t (date.c from section 4.1.1).

4

Hmm so looks like maybe there isn’t an easy solution?

5

Per https://github.com/espressif/esp-idf/issues/584#issuecomment-1157594177 this was fixed in the GCC11 toolchain, but by default PlatformIO still uses the 8.4.0 toolchain, as does the Arduino IDE with the latest stable 2.0.14 release.

PACKAGES:
 - framework-arduinoespressif32 @ 3.20011.230801 (2.0.11)
 - tool-esptoolpy @ 1.40501.0 (4.5.1)
 - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5

Per https://github.com/platformio/platform-espressif32/issues/1211 you can use a third-party platform that uses the updated Arduino-ESP32 3.x package with the corresponding toolchain upgrade.

[env:esp32dev]
platform = https://github.com/Jason2866/platform-espressif32.git#Arduino/IDF5
board = esp32dev
framework = arduino

will do

grafik

This will hopefully be back-integrated into the official Espressif32 at some point. However, Arduino-ESP32 3.x is not even out of Alpha yet.

Another point to make would be that I don’t think that each and every firmware will per-sé break in year 2038. Some code would have to explicitly use that datatype and the associated functions in a non-rollover safe way to trigger a bug. If you use times and timestamps as recommended, that should be fine.

6

Appreciate the response – glad to know a fix is in the pipeline already.