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 akira
Recipients ajaksu2, akira, belopolsky, brett.cannon, daniel.urban, doerwalter, eric.araujo, ggenellina, kawai, l0nwlf, mark.dickinson, pitrou, r.david.murray, rafe, techtonik, tim.peters
Date 2010-06-11.23:48:59
SpamBayes Score 0.0055869003
Marked as misclassified No
Message-id <>
Minor notes:

   1. The constructor now accepts only whole number of minutes in [-23:59, 23:59] range.

rfc 3339 provides the following example:


   This represents the same instant of time as noon, January 1, 1937,
   Netherlands time.  Standard time in the Netherlands was exactly 19
   minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through
   1937-06-30.  This time zone cannot be represented exactly using the
   HH:MM format, and this timestamp uses the closest representable UTC

The presence of fractions of seconds in time zone is an exception so
it might not be worth to support it but it exists.

   Similarly, should str(timezone.utc) be '+0000' or 'UTC' or '+00:00'?

Excerpts in favor for '+00:00' from rfc 3339:

   Attempts to label local offsets with alphabetic
   strings have resulted in poor interoperability in the past [IMAIL],
   [HOST-REQ].  As a result, RFC2822 [IMAIL-UPDATE] has made numeric
   offsets mandatory.

   If the time in UTC is known, but the offset to local time is unknown,
   this can be represented with an offset of "-00:00".  This differs
   semantically from an offset of "Z" or "+00:00", which imply that UTC
   is the preferred reference point for the specified time.
Date User Action Args
2010-06-11 23:49:02akirasetrecipients: + akira, tim.peters, doerwalter, brett.cannon, mark.dickinson, belopolsky, ggenellina, pitrou, techtonik, ajaksu2, kawai, eric.araujo, r.david.murray, rafe, daniel.urban, l0nwlf
2010-06-11 23:49:01akirasetmessageid: <>
2010-06-11 23:49:00akiralinkissue5094 messages
2010-06-11 23:48:59akiracreate