[Python-ideas] Making datetime __str__ and isoformat more consistent

[MRAB]

On 02/11/2013 02:17, Alexander Belopolsky wrote:
>
> On Fri, Nov 1, 2013 at 9:52 PM, Andrew Barnert <abarnert at yahoo.com
> <mailto:abarnert at yahoo.com>> wrote:
>
>     The first is that this would imply that ISO is _the_ format for
>     datetimes, rather than just _a_ format. If you ask a normal person
>     for an integer, unless he's got the Super Bowl in the brain, int
>     will parse his input. Ask him for a date, and it's very unlikely
>     it'll be in ISO format.
>
>
> I don't see how this is a problem.   *The* format for Python datetime is
> the output of print:
>
>  >>> from datetime import datetime
>  >>> print(datetime.now())
> 2013-11-01 22:06:47.774767
>
> It also happened to be ISO compliant.
>
>
>
>     The second problem is false positives. "2003" is a valid ISO date
>     string, equivalent to "20030101" or "20030101T00:00:00". But in most
>     contexts you wouldn't want that interpreted as a valid date or
>     datetime. John Nagle's comment on the tracker
>     (http://bugs.python.org/issue15873#msg169966) explains a similar
>     concern.
>
>
> I would start with date/datetime() just accepting str(x) as input for
> any date/datetime instance.   Full-featured ISO-compliant date/time
> parsing is better left for third-party packages.
>
>     Finally, I'd be happy with a fromisoformat that _only_ handled the
>     output from the isoformat function, but a general constructor would
>     seem incomplete unless it handled all of ISO 8601, or at least all
>     of RFC 3339. That isn't exactly _hard_ (the RFC was meant to be
>     implementable, after all), but it's a higher bar than needed for the
>     problem that started this thread.
>
>
> As long as the general constructor can handle str() output it seems to
> be complete to me.
>
+1

Guaranteeing round-trip does seem like a reasonable behaviour to me.

For anything else, be explicit with strftime and strptime.