Repository navigation
timezone constants in time module inaccurate with negative DST (e.g. Ireland) #83985
Description
| BPO | 39804 |
|---|---|
| Nosy | @malemburg, @abalkin, @pganssle |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2020-03-01.02:17:30.267>
labels = ['3.8', 'type-bug', '3.7', '3.9']
title = 'timezone constants in time module inaccurate with negative DST (e.g. Ireland)'
updated_at = <Date 2020-03-01.02:17:30.267>
user = 'https://github.com/pganssle'bugs.python.org fields:
activity = <Date 2020-03-01.02:17:30.267>
actor = 'p-ganssle'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2020-03-01.02:17:30.267>
creator = 'p-ganssle'
dependencies = []
files = []
hgrepos = []
issue_num = 39804
keywords = []
message_count = 1.0
messages = ['363037']
nosy_count = 3.0
nosy_names = ['lemburg', 'belopolsky', 'p-ganssle']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue39804'
versions = ['Python 3.6', 'Python 3.7', 'Python 3.8', 'Python 3.9']
Activity
pganssle commentedon Mar 1, 2020
From a report on the dateutil tracker today, I found that
time.timezoneandtime.altzoneare not accurate in Ireland (at least on Linux, not tested on other platforms): dateutil/dateutil#1009Europe/Dublin in the modern era has the exact same rules as Europe/London, but the values for
isdstare switched, so for Ireland GMT is the "DST" zone with a DST offset of -1H, and IST is the standard zone, while London has GMT as the standard zone and BST as a DST zone of +1h.The documentation for the timezone constants here pretty clearly say that the DST zone should be the *second* value in tzname, and should be the offset for altzone: https://docs.python.org/3/library/time.html#timezone-constants
But when setting my TZ variable to Europe/Dublin I get the same thing as for Europe/London:
$ TZ=Europe/Dublin python -c \ "from time import *; print(timezone); print(altzone); print(tzname)"0
-3600
('GMT', 'IST')
$ TZ=Europe/London python -c \
"from time import *; print(timezone); print(altzone); print(tzname)"
0
-3600
('GMT', 'BST')
This would be less of a problem if localtime() were *also* getting isdst wrong in the same way, but it's not:
So now it seems that there's no way to determine what the correct timezone offset and name are based on isdst. I'm not entirely sure if this is an issue in our code or a problem with the system APIs we're calling. This code looks like a *very* dicey heuristic (I expect it would also have some problems with Morocco in 2017, even before they were using a type of negative DST, since they used DST but turned it off from May 21st to July 2nd):
cpython/Modules/timemodule.c
Line 1612 in 0b0d29f
One option might be to deprecate these things as sort of very leaky abstractions *anyway* and be done with it, but it might be nice to fix it if we can.
StanFromIreland commentedon May 7, 2025
There is now a buildbot that will fail from this bug for the next few months.
The following tests fail:
test_time,test_strptime, andtest_strftime.I will look into a possible fix. Otherwise, we can just set the timezone for the test.
Lib/tests/test_time.pyif ran withEurope/Dublinlocale #144849 as a duplicate of this issue