classification
Title: extend strftime/strptime format for RFC3339 and RFC2822
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.5
process
Status: closed Resolution: duplicate
Dependencies: Superseder: datetime: add ability to parse RFC 3339 dates and times
View: 15873
Assigned To: belopolsky Nosy List: belopolsky, cvrebert, davydov, eric.araujo, ezio.melotti, mihaic, mribecky, r.david.murray, tinchester, vadmium
Priority: normal Keywords:

Created on 2009-02-10 17:06 by davydov, last changed 2014-06-30 01:04 by belopolsky. This issue is now closed.

Messages (10)
msg81565 - (view) Author: Iakov Davydov (davydov) Date: 2009-02-10 17:06
Currently there is no obvious way to parse time from ISO
8601/W3C/RFC3339 date&time format (http://www.ietf.org/rfc/rfc3339.txt)
or RFC2822. (Actually RFC2822 could be parsed with rfc822 module but
that is not very good way).

I suggest that we should add special directive (let's say %o) for time
offset which is "Z" or ("+" / "-") time-hour ":" time-minute.

Also %O directive will parse zone:  ( "+" / "-" ) time-hour time-minute.
(I suppose there is no need to support obsolate time zones but if that
is possible it's also good idea).
msg97821 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-01-15 16:38
See also issue 655194.
msg97823 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-01-15 16:49
I mean issue 665194.
msg107630 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-12 06:26
%O is used by POSIX spec to indicate alternative locale format.

Gnu date uses %:z 

       %:z    +hh:mm numeric timezone (e.g., -04:00)

	      %::z +hh:mm:ss numeric time zone (e.g., -04:00:00) %:::z numeric
	      time  zone  with : to necessary precision (e.g., -04, +05:30)
msg185813 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2013-04-02 04:54
I've no idea if this is of any use but thought I'd reference it anyway https://pypi.python.org/pypi/strict-rfc3339
msg220699 - (view) Author: Martin Panter (vadmium) * Date: 2014-06-16 05:28
For RFC 2822, perhaps email.utils.parsedate() is good enough?

For RFC 3339, Issue 15873 has been opened for the "datetime" module. It has more discussion and code, so perhaps this bug can be closed as a duplicate?
msg220718 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-06-16 13:17
Yes, I think that is appropriate.  Note that you also get RFC822 parsing for datetime via email.util.parsedate_to_datetime.

(I'm not sure why the OP thought that using the email utilities to parse email-standard dates was "not [a] very good way".)
msg220731 - (view) Author: Iakov Davydov (davydov) Date: 2014-06-16 15:28
ISO 8601 is meant as the standard way to provide an unambiguous and well-defined method of representing dates and times. And the fact that it is widely used in e-mails doesn't make it e-mail specific.

Incorporating function parsedate_to_datetime to email.util is acceptable. But the fact that standard python datetime library doesn't have means to parse ISO-approved time format seems strange to me.

Once again: ISO 8601 is not a e-mail specific format. So I do not see a reason why parsing it is possible only via email.

Using different time-parsing functions in different libraries seems like a bad design to me.
msg220739 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-06-16 16:34
Supporting ISO 8601 is quite different from supporting RFC2822 dates, as far as I can see, and the latter clearly belongs in the email library (especially considering that RFC2822 parsing must follow Postel's Law and accept "dirty" data).  

If you want to open an issue to add ISO 8601 support (as opposed to RFC 3339's 8601 profile+timezone-deviation that is already covered by issue 15873) to datetime, go ahead.  I haven't read enough to understand the details, so I don't know quite what that would mean, or how useful it would be.
msg220740 - (view) Author: Iakov Davydov (davydov) Date: 2014-06-16 16:50
I took a closer look for #15873. Apperently it solves the issue.
Thanks, David.
History
Date User Action Args
2014-06-30 01:04:57belopolskysetstatus: open -> closed
versions: + Python 3.5, - Python 3.4
2014-06-16 16:50:16davydovsetmessages: + msg220740
2014-06-16 16:34:08r.david.murraysetmessages: + msg220739
2014-06-16 15:28:22davydovsetmessages: + msg220731
2014-06-16 13:17:15r.david.murraysetresolution: duplicate
stage: test needed -> resolved
2014-06-16 13:17:03r.david.murraysetsuperseder: datetime: add ability to parse RFC 3339 dates and times
messages: + msg220718
2014-06-16 05:28:00vadmiumsetmessages: + msg220699
2014-06-16 05:02:03vadmiumsetnosy: + vadmium
2014-03-13 17:43:28tinchestersetnosy: + tinchester
2014-03-11 19:24:28cvrebertsetnosy: + cvrebert
2014-02-03 18:35:32BreamoreBoysetnosy: - BreamoreBoy
2013-04-02 19:08:32berker.peksagsetversions: + Python 3.4, - Python 3.2
2013-04-02 04:54:53BreamoreBoysetnosy: + BreamoreBoy
messages: + msg185813
2010-11-18 23:41:45mihaicsetnosy: + mihaic
2010-06-12 06:26:27belopolskysetassignee: belopolsky

messages: + msg107630
nosy: + belopolsky
2010-04-09 04:09:30ezio.melottisetnosy: + ezio.melotti
2010-04-09 02:51:16eric.araujosetnosy: + eric.araujo
2010-01-15 16:49:19r.david.murraysetmessages: + msg97823
2010-01-15 16:38:06r.david.murraysetpriority: normal
versions: + Python 3.2
nosy: + r.david.murray

messages: + msg97821

stage: test needed
2009-09-17 19:01:58mribeckysetnosy: + mribecky
2009-02-10 17:06:02davydovcreate