Repository navigation
ZoneInfo evaluates TZ rule J59 as February 29 in leap years #159714
Description
Bug report
import datetime
import io
import struct
import zoneinfo
from zoneinfo import _zoneinfo
def tzif(footer: bytes) -> io.BytesIO:
# A TZif v3 file with no explicit transitions.
header = b"TZif3" + b"\0" * 15 + struct.pack(">6l", 0, 0, 0, 0, 1, 4)
body = struct.pack(">lbb", 0, 0, 0) + b"STD\0"
return io.BytesIO(header + body + header + body + b"\n" + footer + b"\n")
for implementation in (zoneinfo, _zoneinfo):
tz = implementation.ZoneInfo.from_file(tzif(b"STD0DST-1,J59/0,J300/0"))
print(implementation.__name__)
for year in (2023, 2024):
local = datetime.datetime(year, 2, 28, 12, tzinfo=tz)
print(local.date(), local.tzname())Output:
zoneinfo
2023-02-28 DST
2024-02-28 STD
zoneinfo._zoneinfo
2023-02-28 DST
2024-02-28 STD
I would expect DST in both years. The Jn form excludes February 29, so J59 is February 28 in every year, and J60 is March 1. Both implementations instead interpret J59 as February 29 in a leap year. glibc's tzset() gives DST for February 28, 2024 with the same TZ string.
The leap-year adjustment starts at d >= 59 in the pure-Python implementation and day >= 59 in the C implementation. I think both conditions need to start at 60, because February 28 does not need to move to account for the leap day. The comment immediately above the C condition already describes the intended behavior correctly.
Activity
gh-159714: Fix `ZoneInfo` Julian day 59 in leap years (#159721)
[3.14] gh-159714: Fix `ZoneInfo` Julian day 59 in leap years (GH-159721…
[3.15] gh-159714: Fix `ZoneInfo` Julian day 59 in leap years (GH-159721…