Author ncoghlan
Recipients Neil Muller, amaury.forgeotdarc, andersjm, belopolsky, catlee, davidfraser, eric.araujo, erik.stephens, guettli, hodgestar, jamesh, jribbens, loewis, mark.dickinson, ncoghlan, pboddie, pitrou, r.david.murray, rhettinger, steve.roberts, techtonik, tim.peters, tomster, vstinner, werneck
Date 2012-02-22.04:35:55
SpamBayes Score 3.23772e-05
Marked as misclassified No
Message-id <1329885363.04.0.682987816188.issue9527@psf.upfronthosting.co.za>
In-reply-to
Content
One important thing to remember is that once a time is in the past, whether or not DST was in effect for that time *is never going to change*. That means converting a DST aware timezone to a fixed offset timezone will work just fine for historical times.

It's mainly applications that need to handle times in the *future* (where the DST dates are still subject to change) that have to be aware of the problems when trying to handle DST with fixed offset timezone objects.

I think it's sufficient if the documentation pushes developers of such applications towards modules like pytz and dateutil to get access to variable offset tzinfo implementations.
History
Date User Action Args
2012-02-22 04:36:03ncoghlansetrecipients: + ncoghlan, tim.peters, loewis, jribbens, rhettinger, pboddie, jamesh, guettli, amaury.forgeotdarc, mark.dickinson, davidfraser, belopolsky, pitrou, andersjm, catlee, vstinner, techtonik, tomster, werneck, hodgestar, Neil Muller, eric.araujo, erik.stephens, steve.roberts, r.david.murray
2012-02-22 04:36:03ncoghlansetmessageid: <1329885363.04.0.682987816188.issue9527@psf.upfronthosting.co.za>
2012-02-22 04:35:56ncoghlanlinkissue9527 messages
2012-02-22 04:35:55ncoghlancreate