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 belopolsky
Recipients ajaksu2, belopolsky, daniel.urban, eric.araujo, l0nwlf, r.david.murray, techtonik
Date 2010-06-04.15:07:26
SpamBayes Score 0.00045078393
Marked as misclassified No
Message-id <1275664049.28.0.385189432088.issue7584@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.
History
Date User Action Args
2010-06-04 15:07:29belopolskysetrecipients: + belopolsky, techtonik, ajaksu2, eric.araujo, r.david.murray, daniel.urban, l0nwlf
2010-06-04 15:07:29belopolskysetmessageid: <1275664049.28.0.385189432088.issue7584@psf.upfronthosting.co.za>
2010-06-04 15:07:27belopolskylinkissue7584 messages
2010-06-04 15:07:26belopolskycreate