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

See also issue 655194.

I mean issue 665194.

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

I've no idea if this is of any use but thought I'd reference it anyway https://pypi.python.org/pypi/strict-rfc3339

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?

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".)

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.

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.

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