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-13.16:06:24
SpamBayes Score 0.026211303
Marked as misclassified No
Message-id <1276445189.28.0.462380146536.issue5094@psf.upfronthosting.co.za>
In-reply-to
Content
Just to add a little bit of historical perspective, this proposal is really more than seven years old:

"""
s.keim (Dec 20, 2002 3:33 am; Comment #13)

.. do we really need methods like utcnow. I believe the following could be a little more easy to learn:

* the module define an UTC tzinfo object

* the module define an UTC tzinfo object instead of utcfromtimestamp(x) and utcnow(), the user can use fromtimestamp(x, tzinfo=UTC) and now(tzinfo=UTC)
""" http://www.zope.org/Members/fdrake/DateTimeWiki/SuggestedRequirements

Apparently, this proposal have been forgotten and reinvented again in msg106411, point 2.
History
Date User Action Args
2010-06-13 16:06:29belopolskysetrecipients: + 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-13 16:06:29belopolskysetmessageid: <1276445189.28.0.462380146536.issue5094@psf.upfronthosting.co.za>
2010-06-13 16:06:25belopolskylinkissue5094 messages
2010-06-13 16:06:24belopolskycreate