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.03:41:29
SpamBayes Score 0.0020681028
Marked as misclassified No
Message-id <AANLkTinuYn7pp2bVgqBl_AYJRzKeUsEOuhmTyNFgOEAb@mail.gmail.com>
In-reply-to <1274756800.67.0.166523412485.issue5094@psf.upfronthosting.co.za>
Content
On Mon, May 24, 2010 at 11:06 PM, Rafe Kaplan <report@bugs.python.org> wrote:
..
> On 2, we had discussions about how to pass parameters in to utcnow that we DID record.  When I
> suggested it, Brett said:
>
>  "...using a boolean flag over an argument is much less error-prone for a developer from passing in the wrong
> timezone object; passing in something other than an instance of UTC would just be stupid so we should make
> sure the developer isn't stupid. =)"

Well, I respectfully disagree.  This advise seems to be placing
convenience of the writer of the code over that of the reader.
Imagine encountering an expression datetime.utcnow(True) allowed by
your current patch and trying to figure out what it means.  This can
be improved by making tz_aware a keyword only argument, but in that
case a separate datetime.tz_aware_utcnow() function seems like a
better choice.

Note that I am not suggesting passing anything to utcnow().  I would
either leave it unchanged or make it always return aware datetime
instances.  (Note that with singleton UTC timezone naive datetime
instances can be deprecated with no performance penalty.)
History
Date User Action Args
2010-05-25 03:41:33belopolskysetrecipients: + belopolsky, doerwalter, brett.cannon, ggenellina, pitrou, vstinner, ajaksu2, kawai, eric.araujo, rafe
2010-05-25 03:41:30belopolskylinkissue5094 messages
2010-05-25 03:41:29belopolskycreate