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 brett.cannon
Recipients ajaksu2, belopolsky, brett.cannon, doerwalter, eric.araujo, ggenellina, kawai, pitrou, rafe, vstinner
Date 2010-06-02.21:23:59
SpamBayes Score 0.00013568517
Marked as misclassified No
Message-id <>
My thoughts on Alexander's questions:

1. Call it FixedTimezone or something (remember it has to be CapWords). Calling it simply Timezone does not convey the fact that DST is not supported and people might naively think it will. Its limited abilities should be portrayed in the name.

2. Keep the class dead-simple. The primary motivator is to support UTC, maybe the %z directive for strptime. Otherwise everything else should be left out of the stdlib and let third-parties manage it as they will be the ones that need to manage the bazillion timezone instances they need. We don't need to dictate an interface to them.

3. Taking a timedelta makes sense since the class represents the fixed time offset from UTC.

As for the tz_aware argument to utcnow and friends, I am fine with letting go of them if we have a utc attribute on datetime and we simply document that to get a UTC-aware value do ``now(datetime.utc)`` and consider deprecating utcnow.
Date User Action Args
2010-06-02 21:24:02brett.cannonsetrecipients: + brett.cannon, doerwalter, belopolsky, ggenellina, pitrou, vstinner, ajaksu2, kawai, eric.araujo, rafe
2010-06-02 21:24:02brett.cannonsetmessageid: <>
2010-06-02 21:24:00brett.cannonlinkissue5094 messages
2010-06-02 21:23:59brett.cannoncreate