[Python-ideas] strptime without second argument as an inverse to __str__

[Akira Li]

Andrew Barnert
<abarnert at yahoo.com.dmarc.invalid> writes:

> On Aug 5, 2014, at 14:46, Petr Viktorin
> <encukou at gmail.com> wrote:
>> When people say "iso" in the context of datestimes, they usually mean RFC 3339.
>
> RFC 3339 is still more complicated than just reversing Python's str or
> isoformat. IIRC (it's hard to check on my phone), it mandates that
> parsers should accept 2-digit years (including 3-digit or
> semicolon-and-two-digit years), lowercase T and Z, missing "-", and
> other things that you shouldn't generate but some code might.

Please, don't spread misinformation.

Among the explicit rfc 3339 design goals are simplicity and human
readability. 

Just read http://tools.ietf.org/html/rfc3339 (for an rfc it is
relatively short and readable). Here's full ABNF:

  date-fullyear   = 4DIGIT
  date-month      = 2DIGIT  ; 01-12
  date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                            ; month/year
  time-hour       = 2DIGIT  ; 00-23
  time-minute     = 2DIGIT  ; 00-59
  time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                            ; rules
  time-secfrac    = "." 1*DIGIT
  time-numoffset  = ("+" / "-") time-hour ":" time-minute
  time-offset     = "Z" / time-numoffset

  partial-time    = time-hour ":" time-minute ":" time-second
                    [time-secfrac]
  full-date       = date-fullyear "-" date-month "-" date-mday
  full-time       = partial-time time-offset

  date-time       = full-date "T" full-time

Example:

  1937-01-01T12:00:27.87+00:20


The format is so simple that people just write adhoc parsers using
strptime() without installing any formal rfc3339 module (if it even
exists). 

> That being said, it's still obviously easier to write an RFC 3339
> parser than a full ISO 8601 parser, and as long as someone is willing
> to write it (with sufficient tests) I don't see any problem with the
> stdlib having one. But I don't know that it should be called
> "fromisostring".
>
> "fromisoformat" isn't quite as bad, since at least it implies that
> it's the inverse of the same type's "isoformat", but it still seems
> misleading.


--
Akira