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 rafe
Recipients ajaksu2, belopolsky, brett.cannon, doerwalter, eric.araujo, ggenellina, kawai, pitrou, rafe, vstinner
Date 2010-05-25.03:06:37
SpamBayes Score 0.34159747
Marked as misclassified No
Message-id <1274756800.67.0.166523412485.issue5094@psf.upfronthosting.co.za>
In-reply-to
Content
Alexander, about 1, that's a pretty good question.  I had originally wanted to do something like that but Brett Cannon at the time thought it was not the right approach.  I don't recall the details.  Maybe Brett can recall.  I think we had that conversation in person and it was a long time ago :(

I had originally thought of doing the class, and then having constants associated with it:

  UTC.UTC0

Eventually if we support multiple timezones:

  UTC.UTC1
  UTC.UTC2
  UTC.UTC_1
  UTC.UTC_2

Well... maybe not given how impossible the naming would be.

I think we also talked about redefining new so that it would always return the same global instance.

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. =)"
History
Date User Action Args
2010-05-25 03:06:41rafesetrecipients: + rafe, doerwalter, brett.cannon, belopolsky, ggenellina, pitrou, vstinner, ajaksu2, kawai, eric.araujo
2010-05-25 03:06:40rafesetmessageid: <1274756800.67.0.166523412485.issue5094@psf.upfronthosting.co.za>
2010-05-25 03:06:39rafelinkissue5094 messages
2010-05-25 03:06:37rafecreate