How to solve for the 2038 problem

[remcoNL]

This is the 2038 problem. If timeInt32 is too large (for example 2527507687 which is 2050) i suspect there is a rollover because i end up in early 1900. (-;

Is there something we can do to allow for higher values in this code?

Or maybe it is a lib problem: espressif/esp-idf#584

[lbernstone]

I use uint32_t for the input, so should be good for another 100 years. The rest of the code is in esp-idf, so if they go to 64-bit on the backend, I'll fix this to match. I promise to get it done some time in the next decade.

[lbernstone]

Looks like 64 bit time will be coming in IDF 5.
https://docs.espressif.com/projects/esp-idf/en/v4.1-beta2/api-reference/kconfig.html#config-sdk-toolchain-supports-time-wide-64-bits