How to handle year 2038 bug with ESP32/PIO?

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

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
#define _TIME_T_ __int_least64_t

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: )


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

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

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

Per 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.

 - 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 you can use a third-party platform that uses the updated Arduino-ESP32 3.x package with the corresponding toolchain upgrade.

platform =
board = esp32dev
framework = arduino

will do


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.

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