Joe Peterson <[email protected]> added the comment:
More info on the Europe/London "near the epoch" thing (there is no weirdness in
the tz stuff - it's just issue 10941 causing the test to fail)...
I looked at the sources for the tz data, and here is the definition for
Europe/London:
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Europe/London -0:01:15 - LMT 1847 Dec 1 0:00s
0:00 GB-Eire %s 1968 Oct 27
1:00 - BST 1971 Oct 31 2:00u
0:00 GB-Eire %s 1996
0:00 EU GMT/BST
I appears that London was always 1 hour ahead (BST time) from 1968 Oct 27 until
1971 Oct 31 2:00u, thus triggering issue 10941:
Internaldate2tuple() actually returns the wrong local time (00:00 rather than
[the correct] 01:00) in its tuple for the epoch, so mktime(), doing the right
thing, returns -3600. The patch in issue 10941 fixes this, so the right local
time in London (01:00) is returned for the epoch (internal date string
"01-Jan-1970 00:00:00 +0000").
Note that this also exposes another problem with Time2Internaldate(), since it
uses time.timezone/time.altzone, which are only valid for the current rules,
not old rules as in the London case near the epoch.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue10939>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
