[Python-Dev] iso8601 parsing

[Wes Turner]

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.
https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators

I might be wrong, but I think many of the third party libraries listed here
default to either UTC or timezone-naieve timezones:
https://github.com/vinta/awesome-python/blob/master/README.md#date-and-time

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:
https://docs.python.org/3/library/datetime.html#datetime.time.tzname



> 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
sometimes:
http://docs.astropy.org/en/stable/time/#inferring-input-format

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>