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

[Alexander Belopolsky]

On Fri, Nov 1, 2013 at 9:52 PM, Andrew Barnert <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131101/e42af02c/attachment-0001.html>