This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: zoneinfo gives incorrect dst() in Europe/Madrid in 1938
Type: Stage:
Components: Library (Lib) Versions: Python 3.10, Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: p-ganssle Nosy List: p-ganssle
Priority: normal Keywords:

Created on 2020-06-09 20:21 by p-ganssle, last changed 2022-04-11 14:59 by admin.

Messages (1)
msg371137 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2020-06-09 20:21
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.
History
Date User Action Args
2022-04-11 14:59:32adminsetgithub: 85103
2020-06-09 20:21:28p-gansslecreate