Repository navigation
extend strftime/strptime format for RFC3339 and RFC2822 #49457
Description
| BPO | 5207 |
|---|---|
| Nosy | @abalkin, @ezio-melotti, @merwok, @bitdancer, @mihaic, @vadmium, @Tinche |
| Superseder |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/abalkin'
closed_at = <Date 2014-06-30.01:04:57.157>
created_at = <Date 2009-02-10.17:06:02.595>
labels = ['type-feature', 'library']
title = 'extend strftime/strptime format for RFC3339 and RFC2822'
updated_at = <Date 2014-06-30.01:04:57.155>
user = 'https://bugs.python.org/davydov'bugs.python.org fields:
activity = <Date 2014-06-30.01:04:57.155>
actor = 'belopolsky'
assignee = 'belopolsky'
closed = True
closed_date = <Date 2014-06-30.01:04:57.157>
closer = 'belopolsky'
components = ['Library (Lib)']
creation = <Date 2009-02-10.17:06:02.595>
creator = 'davydov'
dependencies = []
files = []
hgrepos = []
issue_num = 5207
keywords = []
message_count = 10.0
messages = ['81565', '97821', '97823', '107630', '185813', '220699', '220718', '220731', '220739', '220740']
nosy_count = 10.0
nosy_names = ['belopolsky', 'mribecky', 'ezio.melotti', 'eric.araujo', 'r.david.murray', 'davydov', 'cvrebert', 'mihaic', 'martin.panter', 'tinchester']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '15873'
type = 'enhancement'
url = 'https://bugs.python.org/issue5207'
versions = ['Python 3.5']
Activity
davydov commentedon Feb 10, 2009
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).
bitdancer commentedon Jan 15, 2010
See also bpo-655194.
bitdancer commentedon Jan 15, 2010
I mean bpo-665194.
abalkin commentedon Jun 12, 2010
%O is used by POSIX spec to indicate alternative locale format.
Gnu date uses %:z
BreamoreBoy commentedon Apr 2, 2013
I've no idea if this is of any use but thought I'd reference it anyway https://pypi.python.org/pypi/strict-rfc3339
vadmium commentedon Jun 16, 2014
For RFC 2822, perhaps email.utils.parsedate() is good enough?
For RFC 3339, bpo-15873 has been opened for the "datetime" module. It has more discussion and code, so perhaps this bug can be closed as a duplicate?
bitdancer commentedon Jun 16, 2014
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".)
davydov commentedon Jun 16, 2014
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.
bitdancer commentedon Jun 16, 2014
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 bpo-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.
davydov commentedon Jun 16, 2014
I took a closer look for bpo-15873. Apperently it solves the issue.
Thanks, David.