Message127494
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. |
|
Date |
User |
Action |
Args |
2011-01-29 22:48:00 | lavajoe | set | recipients:
+ lavajoe, georg.brandl, belopolsky, benjamin.peterson |
2011-01-29 22:47:59 | lavajoe | set | messageid: <1296341279.99.0.372488457466.issue10939@psf.upfronthosting.co.za> |
2011-01-29 22:47:59 | lavajoe | link | issue10939 messages |
2011-01-29 22:47:59 | lavajoe | create | |
|