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, belopolsky, brett.cannon, doerwalter, eric.araujo, ggenellina, kawai, pitrou, rafe, vstinner
Date 2010-05-25.21:59:06
SpamBayes Score 0.0006316671
Marked as misclassified No
Message-id <1274824748.12.0.741476459831.issue5094@psf.upfronthosting.co.za>
In-reply-to
Content
Roundup bug bites again.  Reposting via web:

-----
On Tue, May 25, 2010 at 5:35 PM, Brett Cannon <report@bugs.python.org> wrote:
>
> The singleton dislike from Antoine and me is that they are generally just not liked in the stdlib.
..
Thanks for the explanation.  I realize that I should not have used the
s-word. :-)  In fact I only wanted a module level constant utc = UTC()
and did not care much about other UTC class instances and whether any
are permitted or easy to create.

> .. so we need to go with what we consider best practice for Python since it will lead to much more use than pytz gets.
>
Well, the datetime module is not exactly the place you want to start
if you want to lead anyone to best Python practices. :-) (Just think
of datetime subclassing from date!)

> Now if a simple FixedOffsetTimeZone class was added and we just pre-populated the datetime module with a utc attribute that contained an
> instance of that class set to the proper values for UTC, that I could support without controversy.

This is exactly my preferred solution.
History
Date User Action Args
2010-05-25 21:59:08belopolskysetrecipients: + belopolsky, doerwalter, brett.cannon, ggenellina, pitrou, vstinner, ajaksu2, kawai, eric.araujo, rafe
2010-05-25 21:59:08belopolskysetmessageid: <1274824748.12.0.741476459831.issue5094@psf.upfronthosting.co.za>
2010-05-25 21:59:07belopolskylinkissue5094 messages
2010-05-25 21:59:06belopolskycreate