[Python-Dev] iso8601 parsing (original) (raw)

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(anint)) == anint so: datetime(str(adatetime)) == adatetime 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>

More information about the Python-Dev mailing list