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 brett.cannon
Recipients ajaksu2, belopolsky, brett.cannon, doerwalter, eric.araujo, ggenellina, kawai, mark.dickinson, pitrou, rafe, vstinner
Date 2010-06-04.05:59:54
SpamBayes Score 0.001404118
Marked as misclassified No
Message-id <1275631197.4.0.125950401515.issue5094@psf.upfronthosting.co.za>
In-reply-to
Content
I'm still leary of supporting any form of DST. A proper DST implementation would need to have some conditional code to account for the datetime object passed into dst, and yet the version you have prototyped doesn't handle it. So a proper timezone supporting DST would still need to subclass any concrete class.

I still say keep it as simple as possible and let users subclass as needed to add DST support. Subclassing __init__ and dst() is not difficult if you want to add proper DST support, especially if dst() is set to return timdelta(0) and utcoffset() always returns CONSTANT + self.dst().

And just to mention it, the instance attributes you had in your example, Alexander, were not "private". For any final code, make sure you make them private else you are asking for trouble from people starting to rely on those attributes.
History
Date User Action Args
2010-06-04 05:59:57brett.cannonsetrecipients: + brett.cannon, doerwalter, mark.dickinson, belopolsky, ggenellina, pitrou, vstinner, ajaksu2, kawai, eric.araujo, rafe
2010-06-04 05:59:57brett.cannonsetmessageid: <1275631197.4.0.125950401515.issue5094@psf.upfronthosting.co.za>
2010-06-04 05:59:55brett.cannonlinkissue5094 messages
2010-06-04 05:59:54brett.cannoncreate