On 2026-07-17 20:00, Robert Elz via tz wrote:
At the time, what was known (by some of us who were working on time
related code, back then) was that there could be up to 2 leap seconds
each year - that they meant perhaps one Dec 31, and another June 30,
was not clear. So the code was written to allow for possibly having
2 at the same time....
Yes, this all sounds right. I looked further, and there's a similar
story in a 2008 Python bug report
<https://bugs.python.org/issue2568#msg125913>, so the Python folks have
long known that Python's support for double leap seconds is bogus but
they still continue to do it for compatibility with older software.
I looked further for why the mistake was in C89, and found the culprit:
it's TZDB's longtime contributor Mark Brader! In 2001 he wrote in the
Usenet group comp.dcom.telecom
<https://groups.google.com/g/comp.dcom.telecom/c/Qq0lwZYG_fI/m/Ttieu9Vu3QIJ>:
If Jay is a C programmer, he may be thinking of section 4.12.1 of the
original ANSI C standard -- which became section 7.12.1 in the first
ISO version -- where it says that the "normal range" of the tm_second
member of a broken-down time is 0 to 61, thus allowing "for as many
as two leap seconds."
I'm afraid it was me who suggested to X3J11 that they needed to allow
for that. I didn't understand the rules for leap seconds fully then
and, evidently, neither did they. I believe it's been corrected in
the new standard.
