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, pitrou, rafe, vstinner
Date 2010-05-25.03:30:34
SpamBayes Score 0.008800279
Marked as misclassified No
Message-id <1274758238.41.0.0940304271793.issue5094@psf.upfronthosting.co.za>
In-reply-to
Content
We didn't do a singleton because I don't like singletons. =) Plus they muck with isinstance/issubclass if you don't expose the class. Basically there is no need to have it be a singleton, so why bother?

And Rafe is right: since utcnow() already exists, why not take advantage of the method? Yes, you could manually call now() with a UTC object, but people are going to notice the utcnow() method and want to use it, so we should make it easy to use the new UTC object on utcnow(). Plus it has the added benefit of providing a transition plan to make utcnow() always return a timezone-aware datetime object.
History
Date User Action Args
2010-05-25 03:30:38brett.cannonsetrecipients: + brett.cannon, doerwalter, belopolsky, ggenellina, pitrou, vstinner, ajaksu2, kawai, eric.araujo, rafe
2010-05-25 03:30:38brett.cannonsetmessageid: <1274758238.41.0.0940304271793.issue5094@psf.upfronthosting.co.za>
2010-05-25 03:30:36brett.cannonlinkissue5094 messages
2010-05-25 03:30:35brett.cannoncreate