New submission from Paul Ganssle <p.gans...@gmail.com>:
Apparently in 1938, Madrid had a "double daylight saving time", where they
transitioned from WET (+0) → WEST (+1) → WEMT (+2) → WEST (+1) → WET (+0):
$ zdump -V -c 1938,1940 'Europe/Madrid'
Europe/Madrid Sat Apr 2 22:59:59 1938 UT = Sat Apr 2 22:59:59 1938 WET
isdst=0 gmtoff=0
Europe/Madrid Sat Apr 2 23:00:00 1938 UT = Sun Apr 3 00:00:00 1938 WEST
isdst=1 gmtoff=3600
Europe/Madrid Sat Apr 30 21:59:59 1938 UT = Sat Apr 30 22:59:59 1938 WEST
isdst=1 gmtoff=3600
Europe/Madrid Sat Apr 30 22:00:00 1938 UT = Sun May 1 00:00:00 1938 WEMT
isdst=1 gmtoff=7200
Europe/Madrid Sun Oct 2 21:59:59 1938 UT = Sun Oct 2 23:59:59 1938 WEMT
isdst=1 gmtoff=7200
Europe/Madrid Sun Oct 2 22:00:00 1938 UT = Sun Oct 2 23:00:00 1938 WEST
isdst=1 gmtoff=3600
Europe/Madrid Sat Oct 7 23:59:59 1939 UT = Sun Oct 8 00:59:59 1939 WEST
isdst=1 gmtoff=3600
Europe/Madrid Sun Oct 8 00:00:00 1939 UT = Sun Oct 8 00:00:00 1939 WET
isdst=0 gmtoff=0
However, zoneinfo reports `.dst()` during the "double daylight saving time"
period as 1 hour:
>>> from datetime import datetime, timedelta
>>> from backports.zoneinfo import ZoneInfo
>>> datetime(1938, 5, 5, tzinfo=ZoneInfo("Europe/Madrid")).dst() /
timedelta(hours=1)
1.0
>>> datetime(1938, 5, 5, tzinfo=ZoneInfo("Europe/Madrid")).tzname()
'WEMT'
I believe the issue is that the "WEMT" is bordered on both sides by DST
offsets, and so the heuristic of "Look for the previous or next non-DST zone
and calculate the difference" doesn't work. We can probably solve this with one
of two heuristics:
1. Allow DST → DST transitions to be included in the calculation of the current
DST, such that when going from x_dst → y_dst, y_dstoff = (y_utcoff - x_utcoff)
+ x_dstoff
2. Look more than 1 transition away to find the nearest STD zone in either
direction, and calculate the offsets from there.
Between this bug and bpo-40930, I suspect we may want to write a rudimentary
parser for `tzdata.zi` to be used only for testing our heuristics, since the
`tzdata.zi` file (shipped with the `tzdata` package), does actually have the
information we want, without resorting to heuristics.
----------
assignee: p-ganssle
components: Library (Lib)
messages: 371137
nosy: p-ganssle
priority: normal
severity: normal
status: open
title: zoneinfo gives incorrect dst() in Europe/Madrid in 1938
versions: Python 3.10, Python 3.9
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue40931>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
