Author techtonik
Recipients ajaksu2, belopolsky, daniel.urban, l0nwlf, merwok, r.david.murray, techtonik
Date 2010-05-26.14:31:44
SpamBayes Score 0.0050218
Marked as misclassified No
Message-id <1274884306.94.0.659192991035.issue7584@psf.upfronthosting.co.za>
In-reply-to
Content
1. David, as an original reporter who needed this for Trac (http://trac.edgewall.org/ticket/8662) and couple of other projects I strongly for 'Z' ending by default, unless you are going to explain the full difference in documentation. Expect to answer the question "Why the timestamp is not 'Z'-ended like in Atom?"

2. "-00:00" is not semantically correct as a default either. Quoting RFC again - "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". It is not true for naive datetime stamps that represent the fact that "the time in UTC is unknown, and the offset to UTC is unknown".

3. Daniel, thanks for yet another patch contribution for this issue. default_utcoffset seems confusing to me. If I see call like datetime.rfcformat(default_utcoffset="-00:00") - I somehow expect that default_utcoffset is used if it is impossible to determine the offset. If it is only about format of zero offset then 'zerozone' param seems more logical. If it is about substitution for unknown zone, then the proper way in datetime API would be to convert object to 'aware datetime' type with proper zone prior to calling this function. Datetime API is definitely on of the worst items in Python from the user point of view.
History
Date User Action Args
2010-05-26 14:31:47techtoniksetrecipients: + techtonik, belopolsky, ajaksu2, merwok, r.david.murray, daniel.urban, l0nwlf
2010-05-26 14:31:46techtoniksetmessageid: <1274884306.94.0.659192991035.issue7584@psf.upfronthosting.co.za>
2010-05-26 14:31:45techtoniklinkissue7584 messages
2010-05-26 14:31:44techtonikcreate