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, belopolsky, daniel.urban, eric.araujo, l0nwlf, r.david.murray, techtonik
Date 2010-06-05.15:19:22
SpamBayes Score 0.0059942068
Marked as misclassified No
Message-id <>
> According to my reading of RFC 3339, it is not correct to produce 'Z'
> timestamps when local offset is not known.

It is not said that 'Z' SHOULD NOT be produced if local offset is unknown. Even if offset is unknown, UTC still can be the preferred reference point for the specified time.

From the user point of view the assumption about "know or unknown offset" is beyond the judgement of low-level datetime library. For example, if I read timestamp of a local file, I assume that local offset is unknown and UTC is not preferred, but still do not have other choice than to write zero. It won't help me to find actual offset. For a network file I assume that preferred offset is actually UTC and although I do not have any means to check the offset I can write zero without any hesitation.

Solving philosophical -00:00 +00:00 problems require a deep knowledge of RFC3339. I doubt that pleasing 1% who need this kind of fine-grained semantic control with special API deserves suffering of other 99%. In the end there is nothing hard in replacing 'Z' with a flavor of your choice.

Of course, if smb. want to force developers to overload their brain for the sake of providing the most accurate semantic timestamps (that nobody uses anyway) - then the -00:00/+00:00 stuff is a way to go. But my opinion is that datetime API in Python is already complicated enough to negatively affect this language karma.
Date User Action Args
2010-06-05 15:19:27techtoniksetrecipients: + techtonik, belopolsky, ajaksu2, eric.araujo, r.david.murray, daniel.urban, l0nwlf
2010-06-05 15:19:26techtoniksetmessageid: <>
2010-06-05 15:19:24techtoniklinkissue7584 messages
2010-06-05 15:19:22techtonikcreate