anatoly techtonik <techto...@gmail.com> added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7584> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
