On Jul 18, 2026, at 9:44 AM, James Bellaire via tz <[email protected]> wrote:
> Keep planning for the eventuality that there could some day be a day where > EST does not equal UTC-05. Hope that it doesn't happen if the coding is too > difficult. And encourage developers to 1) not rely on "EST" in a string meaning UTC-05 etc., 2) stop using "EST" etc. in time stamp strings and switch to UTC±N, and 3) not assume what tm_isdst means. *Our* code doesn't have to be changed, but *other* code may be making inappropriate assumptions that need to be fixed. > And if your code would be affected by a negative leap second you may want to > fix that too. Yes, that's another thing we should encourage others to fix. If our code is using tzdb files that do *not* include leap-second adjustments, it'll behave the way POSIX specifies, meaning it will assume that time_t values are based on every day being exactly 86400 seconds long, which means it will know nothing about negative leap seconds just as it knows nothing about positive leap seconds, and rely on whatever generates or processes time_t values doing the right thing. If our code is using tzdb files that *do* include leap-second adjustments, I think that localtime() will turn the time_t just before the leap second into YYYY-MM-DD 23:59:58 and that value + 1 into 00:00:00 the next day, and mktime() will turn YYYY-MM-DD 23:59:58 into the right value. I'm not sure what mtkime() would do with the invalid input YYYY-MM-DD 23:59:59 - return an error or return the same time_t value that it returns for 00:00:00 the next day? So *our* code probably doesn't need fixing unless it doesn't work correctly when using tzdb files that have leap-second adjustments.
