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-06-02.20:49:46
SpamBayes Score 0.009600813
Marked as misclassified No
Message-id <1275511793.79.0.181481529342.issue5094@psf.upfronthosting.co.za>
In-reply-to
Content
Here is my first attempt to implement fixed offset timezone type.  The patch is based on Brett's next-patch.txt and while I changed the type name from datetime.UTC to datetime.timezone, I did not change the name of the related C structures.  I would like to ask for comments on the following questions:

1. How to call the new type?  I like "timezone" because it is likely to be the only concrete tzinfo subclass in datetime module, so we don't really need to call it fixedoffsetfromutctimezone.

2. Do we want to add a dst indicator and altname attributes? I would say: no. I would rather treat DST as a different fixed offset timezone.

3. I am not quite happy about having to specify offset in minutes.  I think timezone(hours[, minutes]) may be clearer.  Alternatively we may just take offset as a timedelta.  Note issue5288.  There is some interest in supporting sub-minute timezones.

4. I have fixed a reference leak in utcnow, but I am still against giving it tz_aware argument.
History
Date User Action Args
2010-06-02 20:49:54belopolskysetrecipients: + belopolsky, doerwalter, brett.cannon, ggenellina, pitrou, vstinner, ajaksu2, kawai, eric.araujo, rafe
2010-06-02 20:49:53belopolskysetmessageid: <1275511793.79.0.181481529342.issue5094@psf.upfronthosting.co.za>
2010-06-02 20:49:51belopolskylinkissue5094 messages
2010-06-02 20:49:51belopolskycreate