From a report on the dateutil tracker today, I found that `time.timezone` and `time.altzone` are not accurate in Ireland (at least on Linux, not tested on other platforms): https://github.com/dateutil/dateutil/issues/1009

Europe/Dublin in the modern era has the exact same rules as Europe/London, but the values for `isdst` are 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:


$ TZ=Europe/London python -c \
  "from time import *; print(localtime())"
time.struct_time(tm_year=2020, tm_mon=3, tm_mday=1, tm_hour=2, tm_min=5, tm_sec=6, tm_wday=6, tm_yday=61, tm_isdst=0)

$ TZ=Europe/Dublin python -c \
  "from time import *; print(localtime())"
time.struct_time(tm_year=2020, tm_mon=3, tm_mday=1, tm_hour=2, tm_min=5, tm_sec=18, tm_wday=6, tm_yday=61, tm_isdst=1)


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): https://github.com/python/cpython/blob/0b0d29fce568e61e0d7d9f4a362e6dbf1e7fb80a/Modules/timemodule.c#L1612

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.