In <https://github.com/eggert/tz/pull/37> (2026-01-10) the GitHub user Naveed8951 writes:
The TZif specification guarantees that tt_utoff is never INT32_MIN so that 32-bit clients can safely negate it. However, tzloadbody() previously accepted unvalidated values from untrusted TZif input. A malformed or malicious file could therefore trigger signed integer overflow during later offset arithmetic (e.g., negation for timezone / altzone or offset-difference calculations), which is undefined behavior in C.
Naveed8951 submitted a patch that would cause localtime.c to reject TZif files containing UT offsets outside the POSIX range -89999..93599 (-24:59:50 .. 25:59:59), the idea being that small offsets like that would not cause overflow. Unfortunately, I think such a change would still allow undefined behavior in some cases, as overflow could still happen when adding a small offset to a large tm_sec or time_t value. Also, Internet RFC 9636 section 3.2 allows (though it discourages) UT offsets outside the POSIX range. So instead, I fixed localtime.c to handle the outlandish offsets correctly. As a special case, localtime.c (and zic.c) now reject a UT offset exactly equal to -2**31, as RFC 9636 does not allow that and it can easily cause trouble in callers that negate a UT offset stored in a 32-bit integer.