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 techtonik
Recipients ajaksu2, daniel.urban, eric.araujo, l0nwlf, techtonik
Date 2010-05-09.13:31:57
SpamBayes Score 5.2335113e-06
Marked as misclassified No
Message-id <1273411920.05.0.0598998635187.issue7584@psf.upfronthosting.co.za>
In-reply-to
Content
Let's quote RFC 3339:
"""
4.3. Unknown Local Offset Convention

   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.  RFC2822
   [IMAIL-UPDATE] describes a similar convention for email.
"""

The phrase "this CAN be represented" doesn't mean that it SHOULD be represented. Do we have information to decide if offset to local zone is unknown or if UTC is the preferred reference point for specified time? I guess no, and I am afraid that most users just don't care or don't want to bog into details - all they need is a good Atom looking timestamp. As we are not aiming at making a reference library for generating all possible forms of valid RFC 3339 timestamps, it makes sense to use 'Z' in the end because it is easier to handle.

rfcformat(dt).replace("Z", "-00:00") in case somebody need a -00:00 is easier than reverse operation if you need 'Z' in the end:

dstr = rfcformat(dt)
if dstr.endswith("-00:00") or dstr.endswith("+00:00"):
    dstr = dstr[:-6] + 'Z'
History
Date User Action Args
2010-05-09 13:32:00techtoniksetrecipients: + techtonik, ajaksu2, eric.araujo, daniel.urban, l0nwlf
2010-05-09 13:32:00techtoniksetmessageid: <1273411920.05.0.0598998635187.issue7584@psf.upfronthosting.co.za>
2010-05-09 13:31:58techtoniklinkissue7584 messages
2010-05-09 13:31:57techtonikcreate