Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
> It seems to me that we should not try to produce an RFC 3339 compliant > date string from a naive datetime. It will be practical to accept > that restriction once issue 5094 is resolved. Does this mean that t.rfcformat() should fail if t is naive? According to my reading of RFC 3339, it is not correct to produce 'Z' timestamps when local offset is not known. My understanding is that compliant producers must either know their local timezone and specify correct offset in the suffix or produce UTC timestamps with '-00:00'. Consumers receiving a '...Z' timestamp should be able to rely on that to conclude that the producer is in the UTC+0 timezone. Raising an exception when local offset is not known is OK, but I think generating '-00:00' would be more useful. Note that overall I am -1 on this proposal. A naive application can probably get away with datetime.isoformat. A strictly compliant RFC 3339 implementation is beyond the scope of datetime module and belongs to a separate module which should probably support parsing of RFC 3339 timestamps as well. Rather than adding more xxxformat() methods, I would rather see datetime getting a custom __format__ that would be flexible enough to make writing standard formats easy. ---------- _______________________________________ 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
