extend strftime/strptime format for RFC3339 and RFC2822

[davydov]

BPO	5207
Nosy	@abalkin, @ezio-melotti, @merwok, @bitdancer, @mihaic, @vadmium, @Tinche
Superseder	bpo-15873: datetime: add ability to parse RFC 3339 dates and times

^{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']

[davydov]

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]

See also bpo-655194.

[bitdancer]

I mean bpo-665194.

[abalkin]

%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)

[BreamoreBoy]

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]

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]

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]

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]

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]

I took a closer look for bpo-15873. Apperently it solves the issue.
Thanks, David.