Should time_t be avoided?

[henrygab]

MartinMueller2003 wrote:

[ESPixelStick code] is tailored to the ESP product line and time_t has well defined semantics and well understood side effects.

I was fairly sure that time_t wasn't quite that well defined, even for just the ESP product line. My challenge was fairly simple:

Without validating your understanding (e.g., don't check via compilation, documentation, etc.), write down your answers to the following questions on a piece of paper:

1. What is the result of sizeof(time_t)?
2. What is the minimum value that can be stored in time_t?
3. What is the maximum value that can be stored in time_t?
4. Is time_t a signed or unsigned type?
5. What happens when there is overflow on time_t?
6. What happens when there is an underflow on time_t?

After you've written answers to the above (don't have to send them), feel free to verify them programmatically. Here's an example file that you should be able to just drop into an existing project, for example ... just edit (or uncomment) the line at the end according to your expectations ... if you are correct, the file will compile. If not, it will assert during compilation. Try on both ESP8266 and ESP32.

BONUS POINTS:
B1. Also perform experiment on ESP32-C2, ESP32-S3, or other platforms of interest
B2. If time_t is 64-bit, what limits should the code enforce on allowed range?

[MartinMueller2003]

Hi Henry

I have been looking into time_t in general, and I see it has fallen out of favor and I can see why. For ESP it works as expected but is not considered portable. While the intent of the V4 code is not portability, just look at the Arduino implementation of String, which is a good example of braindead behavior and the very unfortunate repurposing of the map functionality and the missing vector support and you will see why much of the code has no chance to be portable. With that said, using uint32_t to replace time_t will have no impact on the system functionality and will align the code with current opinions for "not so bad code". Feel free to update the use of time_t to uint32_t.

[henrygab]

Hi Martin,

Thank you for taking a look at time_t; I really appreciate that you considered my questions, to the point of investigating why opinions might have changed over time (no pun intended).

I would review how the item is used, and choose based on that use. For example, where it's initialized from millis() and used to track an elapsed time using millis(), I might suggest using pfeerick/elapsedMillis@^1.0.6. (That library was originally written by Paul Stoffregen.)

Because current usage of time_t includes being parsed from (and exported to) JSON, it also seems the use of int64_t may be more appropriate, as JavaScript supports 53-bits of precision in the Number type.

P.S. - You are right, the design of String included some ... unfortunate ... decisions. I also fully agree the v4 code is not intended to be generally portable, and that it is currently welded to the Arduino ecosystem.

[henrygab]

I admit that I was surprised by the results.

My personal results from the above thought experiment? (click to expand)

Q	ESP8266	ESP32	Notes
1 - sizeof(time_t)	8 (64-bit)	4 (32-bit)	Yes, the size is larger on ESP8266
4 - signed?	signed	signed	Both ESP8266 and ESP32 store as signed values
2 - min value	INT64_MIN	INT32_MIN
3 - max value	INT64_MAX	INT32_MAX	See extended discussion below
5 - overflow	UB	UB	Undefined behavior, which compiler can optimize away
6 - underflow	UB	UB	Undefined behavior, which compiler can optimize away

Because ESP32 uses 32-bit signed integer, it cannot represent dates past January 18, 2038.

Bonus Question B2

The ESP8266 defines time_t as a 64-bit signed integer. The value is converted to/from JSON, and used in JavaScript (EcmaScript).
JavaScript stores integer values as 64-bit floating point values. In JavaScript, the Number type can only represent 2^53 bits of precision. See 6.1.6.1 The Number Type. Since this project exports to JSON, it's limited to 53-bits of precision for any value being output. I'm not entirely sure what value is returned when the JSON encodes +infinity, -infinity, or -0 (all values that are valid for Number).

How's that for unexpected?

When time_t is 32-bit (ESP32), the JSON library might be returning a value that doesn't actually fit into time_t (and thus increases the risk of overflow/underflow). In contrast, using int64_t makes import from JSON lossless, and while export to JSON might have extreme edge cases that fail ... they're not ones that would realistically be hit with this project.

---

[MartinMueller2003]

Actually, uint32_t is more than enough for millis since it is time since boot since there is no concept of "now" other than setting the timestamp on a downloaded file. Any code that could be impacted by a rollover in millis already has protection against that in the unlikely event that an ESP goes multiple year without a reboot. It is when we use micros that the real issue can come up. That rolls over every few days.