[Python-Dev] iso8601 parsing

Wes Turner wes.turner at gmail.com
Wed Oct 25 22:37:09 EDT 2017

On Wednesday, October 25, 2017, Chris Barker <chris.barker at noaa.gov> wrote:

> On Wed, Oct 25, 2017 at 4:22 PM, Alexander Belopolsky <
> alexander.belopolsky at gmail.com
> <javascript:_e(%7B%7D,'cvml','alexander.belopolsky at gmail.com');>> wrote:
>> > times. The only difference is that instead of calling the type directly,
>> > you call the appropriate classmethod.
>> >
>> > What am I missing?
>> Nothing. The only annoyance is that the data processing code typically
>> needs to know the type anyway, so the classmethod is one more variable
>> to keep track of.
> I don't think anyone is arguing that is is hard to do either way, or that
> hard to use either way.
> I think it comes down to a trade-off between:
> Having an API for datetime that is like the datetime for number types:
>  int(str(an_int)) == an_int
>  so:
>  datetime(str(a_datetime)) == a_datetime
> Alexander strongly supports that.
> Or an API that is perhaps more like the rest of the datetime api, which
> has a number of alternate constructors:
>  datetime.now()
>  datetime.fromordinal()
>  datetime.fromtimestamp()
> And has:
>   datetime.isoformat()
> So a
>    datetime.fromisoformat()
> would make a lot of sense.
> I would note that the number types don't have all those alternate
> constructors Also, the number types mostly have a single parameter (except
> int has an optional base parameter). So I'm not sure the parallel is that
> strong.
> Would it be horrible if we did both?
> After all, right now, datetime has:
> In [16]: dt.isoformat()
> Out[16]: '2017-10-25T16:30:48.744489'
> and
> In [18]: dt.__str__()
> Out[18]: '2017-10-25 16:30:48.744489'
> which do almost the same thing (I understand the "T" is option in iso 8601)
> However, maybe they are different when you add a time zone?
> ISO 8601 support offsets, but not time zones -- presumably the __str__
> supports the full datetime tzinfo somehow. Which may be why .isoformat()
> exists.

ISO8601 does support timezones.

I might be wrong, but I think many of the third party libraries listed here
default to either UTC or timezone-naieve timezones:

Ctrl-F for 'tzinfo=' in the docs really doesn't explain how to just do it
with my local time.

Here's an example with a *custom* GMT1 tzinfo subclass:

> Though I don't think that means you couldn't have the __init__ parse
> proper ISO strings, in addition to the full datetime __str__ results.

What would you call the str argument? Does it accept strptime args or only
ISO8601? Would all of that string parsing logic be a performance regression
from the current constructor? Does it accept None or empty string?


Deserializing dates from JSON (without #JSONLD and xsd:dateTime (ISO8601))
types is nasty, regardless (try/except, *custom* schema awareness). And
pickle is dangerous.

AFAIU, we should not ever eval(repr(dt: datetime)).


Should the date time constructor support nanos= (just like time_ns())?

ENH: Add nanosecond support to the time and datetime constructors


The astropy Time class supports a string argument as the first parameter

Astropy does support a "year zero".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171025/dc9c887e/attachment.html>

More information about the Python-Dev mailing list