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 belopolsky
Recipients ajaksu2, akira, belopolsky, brett.cannon, daniel.urban, doerwalter, eric.araujo, ggenellina, kawai, l0nwlf, mark.dickinson, pitrou, r.david.murray, rafe, techtonik, tim.peters
Date 2010-06-12.16:14:00
SpamBayes Score 0.0006320183
Marked as misclassified No
Message-id <>
I have made my mind on subclassing timezone issue.  I believe subclassing should not be allowed and here is the reason:

The new datetime.timezone class is a very specific implementation of tzinfo interface.  It guarantees that utcoffset(dt) and friends return the same value for all times.  Applications should be able to rely on this and a simple isinstance(tz, timezone) should be enough to deduce that tz is a fixed offset tzinfo instance.  (Of course careful applications can check type(tz) == timezone instead, but making isinstance(tz, timezone) subtly wrong is not a good idea.)

There is also very little to be gained from subclassing timezone.  It defines only 4 methods and each is entirely trivial.  Any non-trivial tzinfo implementation will need to override all 4 of them anyways.  It is much safer to derive from tzinfo directly and possible reuse timezone through containment (for example to format offsets in a standard way.)

The only immediate application of subclassing is to add dst() method returning a fixed offset rather than None.  This is trivial to implement through containment and if such class becomes popular, I would prefer to add this functionality to timezone class itself.
Date User Action Args
2010-06-12 16:14:03belopolskysetrecipients: + belopolsky, tim.peters, doerwalter, brett.cannon, mark.dickinson, ggenellina, pitrou, techtonik, ajaksu2, kawai, eric.araujo, r.david.murray, rafe, daniel.urban, l0nwlf, akira
2010-06-12 16:14:03belopolskysetmessageid: <>
2010-06-12 16:14:01belopolskylinkissue5094 messages
2010-06-12 16:14:00belopolskycreate