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.

Author lavajoe
Recipients belopolsky, benjamin.peterson, georg.brandl, lavajoe
Date 2011-01-29.22:47:59
SpamBayes Score 2.17851e-06
Marked as misclassified No
Message-id <1296341279.99.0.372488457466.issue10939@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2011-01-29 22:48:00lavajoesetrecipients: + lavajoe, georg.brandl, belopolsky, benjamin.peterson
2011-01-29 22:47:59lavajoesetmessageid: <1296341279.99.0.372488457466.issue10939@psf.upfronthosting.co.za>
2011-01-29 22:47:59lavajoelinkissue10939 messages
2011-01-29 22:47:59lavajoecreate