➜

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:14:50
SpamBayes Score 0.00019098808
Marked as misclassified No
Message-id <AANLkTinrZFf-3GRjhZ1cByN1Jp14X-yPzMXB9kgLBdIF@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:
..
> 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
..
>
> Well... maybe not given how impossible the naming would be.
..

I actually like your original idea.  It seems wasteful to create a
concrete timezone class in a C module and only use it for a single
timezone.  FixedOffset class in tzinfo-examples.py is only slightly
more complicated than UTC class and as explained in the comment above
it, "FixedOffset(0, "UTC") is a different way to build a UTC tzinfo
object.  FixedOffset objects can then be used to produce aware
datetime instances from strptime.  (See issue6641.)  I would only
define utc = FixedOffset(0, "UTC") instance and make name argument to
FixedOffset optional defaulting to UTC(+/-)hhmm.
History
Date User Action Args
2010-05-25 21:14:53belopolskysetrecipients: + belopolsky, doerwalter, brett.cannon, ggenellina, pitrou, vstinner, ajaksu2, kawai, eric.araujo, rafe
2010-05-25 21:14:51belopolskylinkissue5094 messages
2010-05-25 21:14:50belopolskycreate