On Mon, Oct 23, 2017 at 5:33 PM, Hasan Diwan <hasan.diwan@gmail.com> wrote:

If one simply replaces the 'T' with a space and trims it after the '.', IIRC, it parses fine.

sure, but really, can anyone argue that it's not a good idea for datetime ot be able to read the iso format it puts out??? -CHB

-- H

On Oct 23, 2017 15:16, "Mike Miller" <python-dev@mgmiller.net> wrote:

...

Hi,

Could anyone put this five year-old bug about parsing iso8601 format date-times on the front burner?

http://bugs.python.org/issue15873

In the comments there's a lot of hand-wringing about different variations that bogged it down, but right now I only need it to handle the output of datetime.isoformat():

>>> dt.isoformat() '2017-10-20T08:20:08.986166+00:00'

Perhaps if we could get that minimum first step in, it could be iterated on and made more lenient in the future.

Thank you, -Mike _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/hasan.diw an%40gmail.com

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ chris.barker%40noaa.gov

-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

On Tuesday, October 24, 2017 5:53:58 PM EDT Alexander Belopolsky wrote:

No, but the last time I suggested that that datetime types should satisfy the same invariants as numbers, namely T(repr(x)) == x, the idea was met will silence. I, on the other hand, am not very enthusiastic about named constructors such as date.isoparse(). Compared with date(s:str), this is one more method name to remember, plus the potential for abuse as an instance method. What is d.isoparse('2017-11-24')?

Agreed. datetime(s:str) seems like a far more natural and consistent choice. Elvis

On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters <tritium-list@sdamon.com> wrote:

Why make parsing ISO time special?

It's not the ISO format per se that is special, but parsing of str(x). For all numeric types, int, float, complex and even fractions.Fraction, we have a roundtrip invariant T(str(x)) == x. Datetime types are a special kind of numbers, but they don't follow this established pattern. This is annoying when you deal with time series where it is common to have text files with a mix of dates, timestamps and numbers. You can write generic code to deal with ints and floats, but have to special-case anything time related.

+1 on a classmethod constructor +0 on a based-on-type default constructor +inf on SOMETHING! Let's get passed the bike shedding and make this work! -CHB On Wed, Oct 25, 2017 at 2:18 PM, Alex Walters <tritium-list@sdamon.com> wrote:

...

-----Original Message----- From: Alexander Belopolsky [mailto:alexander.belopolsky@gmail.com] Sent: Wednesday, October 25, 2017 4:33 PM To: Alex Walters <tritium-list@sdamon.com> Cc: Elvis Pranskevichus <elprans@gmail.com>; Python-Dev <python- dev@python.org>; Chris Barker <chris.barker@noaa.gov> Subject: Re: [Python-Dev] iso8601 parsing

On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters <tritium-list@sdamon.com> wrote:

...

Why make parsing ISO time special?

It's not the ISO format per se that is special, but parsing of str(x). For all numeric types, int, float, complex and even fractions.Fraction, we have a roundtrip invariant T(str(x)) == x. Datetime types are a special kind of numbers, but they don't follow this established pattern. This is annoying when you deal with time series where it is common to have text files with a mix of dates, timestamps and numbers. You can write generic code to deal with ints and floats, but have to special-case anything time related.

...

...

...

repr(datetime.datetime.now()) 'datetime.datetime(2017, 10, 25, 17, 16, 20, 973107)'

You can already roundtrip the repr of datetime objects with eval (if you care to do so). You get iso formatting from a method on dt objects, I don’t see why it should be parsed by anything but a classmethod.

-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

On 26 October 2017 at 07:30, Chris Barker <chris.barker@noaa.gov> wrote:

+1 on a classmethod constructor +0 on a based-on-type default constructor

+inf on SOMETHING!

Let's get passed the bike shedding and make this work!

I'll also note that these aren't either/or outcomes: adding a str-specific classmethod *doesn't* preclude implicitly calling that class method from the default constructor later based on the input type. For example, decimal.Decimal.from_float() was added before the type constructor gained native support for float inputs, due to concerns about potential binary-vs-decimal rounding errors arising from doing such conversions implicitly. So we can add "datetime.fromisoformat(isotime: str)" now, and then *if* we later decide to support the "type(x)(str(x)) == x" numeric invariant for the datetime classes, that can be specified as "If the constructor arguments consist of a single string, that is handled by calling the fromisoformat class method". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Wed, Oct 25, 2017 at 04:32:39PM -0400, Alexander Belopolsky wrote:

On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters <tritium-list@sdamon.com> wrote:

...

Why make parsing ISO time special?

It's not the ISO format per se that is special, but parsing of str(x). For all numeric types, int, float, complex and even fractions.Fraction, we have a roundtrip invariant T(str(x)) == x. Datetime types are a special kind of numbers, but they don't follow this established pattern. This is annoying when you deal with time series where it is common to have text files with a mix of dates, timestamps and numbers. You can write generic code to deal with ints and floats, but have to special-case anything time related.

Maybe I'm just being slow today, but I don't see how you can write "generic code" to convert text to int/float/complex/Fraction, but not times. The only difference is that instead of calling the type directly, you call the appropriate classmethod. What am I missing? -- Steven

On Wed, Oct 25, 2017 at 4:22 PM, Alexander Belopolsky < alexander.belopolsky@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. 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. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

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

On Wed, Oct 25, 2017 at 4:22 PM, Alexander Belopolsky < alexander.belopolsky@gmail.com <javascript:_e(%7B%7D,'cvml','alexander.belopolsky@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".

On Wed, Oct 25, 2017 at 7:37 PM, Wes Turner <wes.turner@gmail.com> wrote:

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

No, it doesn't -- it may call them "timezones", but it only supports offsets -- that is, and offset of -6 could be US Eastern Standard Time or US Central Daylight TIme (or I got that backwards :-) ) The point is that an offset is really easy, and timezones (with Daylight savings and all that) are a frickin' nightmare, but ARE supported by datetime Note that the vocabulary is not precise here, as I see this in the Pyton docs: *class *datetime.timezone A class that implements the tzinfo <https://docs.python.org/3/library/datetime.html#datetime.tzinfo> abstract base class as a fixed offset from the UTC. So THAT is supported by iso8601, and, indeed maps naturally to it. Which means we can round trip isp8601 datetimes nicely, but can't round trip a datetime with a "full featured" tzinfo attached. I don't think this really has any impact on the proposal, though: it's clear what to do when parsing a iso Datetime. 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

This is a key point that I hope is obvious: If an ISO string has NO offset or timezone indicator, then a naive datetime should be created. (I say, I "hope" it's obvious, because the numpy datetime64 implementation initially (and for years) would apply the machine local timezone to a bare iso string -- which was a f-ing nightmare!)

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

Here it is: class GMT1(tzinfo): def utcoffset(self, dt): return timedelta(hours=1) def dst(self, dt): return timedelta(0) def tzname(self,dt): return "Europe/Prague" I hope Prague doesn't do DST, or that would be just wrong ... What would you call the str argument? Does it accept strptime args or only

ISO8601?

I think Fred answered this, but iso 8601 only. we already have strptime if you need to parse anything else. Would all of that string parsing logic be a performance regression from the

current constructor? Does it accept None or empty string?

I suppose you need to do a little type checking first, so a tiny one. Though maybe just catching an Exception, so really tiny. The current constructor only takes numbers, so yes the string parsing version would be slower, but only if you use it... 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)).

why not? isn't that what __repr__ is supposed to do? Or do you mean not that it shouldn't work, but that we shouldn't do it? -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

On Thursday, October 26, 2017, Chris Barker <chris.barker@noaa.gov> wrote:

On Wed, Oct 25, 2017 at 7:37 PM, Wes Turner <wes.turner@gmail.com <javascript:_e(%7B%7D,'cvml','wes.turner@gmail.com');>> wrote:

...

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

No, it doesn't -- it may call them "timezones", but it only supports offsets -- that is, and offset of -6 could be US Eastern Standard Time or US Central Daylight TIme (or I got that backwards :-) )

The point is that an offset is really easy, and timezones (with Daylight savings and all that) are a frickin' nightmare, but ARE supported by datetime

Note that the vocabulary is not precise here, as I see this in the Pyton docs:

*class *datetime.timezone

A class that implements the tzinfo <https://docs.python.org/3/library/datetime.html#datetime.tzinfo> abstract base class as a fixed offset from the UTC. So THAT is supported by iso8601, and, indeed maps naturally to it.

Got it, thanks.

Which means we can round trip isp8601 datetimes nicely, but can't round trip a datetime with a "full featured" tzinfo attached.

Because an iso8601 string only persists the offset.

I don't think this really has any impact on the proposal, though: it's clear what to do when parsing a iso Datetime.

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

This is a key point that I hope is obvious:

If an ISO string has NO offset or timezone indicator, then a naive datetime should be created.

(I say, I "hope" it's obvious, because the numpy datetime64 implementation initially (and for years) would apply the machine local timezone to a bare iso string -- which was a f-ing nightmare!)

astropy.time.Time supports numpy.

...

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

Here it is:

class GMT1(tzinfo): def utcoffset(self, dt): return timedelta(hours=1) def dst(self, dt): return timedelta(0) def tzname(self,dt): return "Europe/Prague"

I hope Prague doesn't do DST, or that would be just wrong ...

Pendulum seems to have a faster timezone lookup than pytz: https://pendulum.eustace.io/blog/a-faster-alternative-to-pyz.html Both pendulum and pytz are in conda-forge (the new basis for the anaconda distribution).

What would you call the str argument? Does it accept strptime args or only

...

ISO8601?

I think Fred answered this, but iso 8601 only. we already have strptime if you need to parse anything else.

Would all of that string parsing logic be a performance regression from

...

the current constructor? Does it accept None or empty string?

I suppose you need to do a little type checking first, so a tiny one.

Though maybe just catching an Exception, so really tiny.

The current constructor only takes numbers, so yes the string parsing version would be slower, but only if you use it...

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)).

why not? isn't that what __repr__ is supposed to do?

repr(dict) now returns ellipses ... for cyclical dicts; so I'm assuming that repr only MAY be eval'able.

Or do you mean not that it shouldn't work, but that we shouldn't do it?

That We shouldn't ever eval untrusted data / code. (That's why we need package hashes, signatures, and TUF).

-CHB

--

Christopher Barker, Ph.D. Oceanographer

Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE <https://maps.google.com/?q=7600+Sand+Point+Way+NE&entry=gmail&source=g> (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov <javascript:_e(%7B%7D,'cvml','Chris.Barker@noaa.gov');>

Here is the PR I've submitted: https://github.com/python/cpython/pull/4699 The contract that I'm supporting (and, I think it can be argued, the only reasonable contract in the intial implementation) is the following: dtstr = dt.isoformat(*args, **kwargs) dt_rt = datetime.fromisoformat(dtstr) assert dt_rt == dt # The two points represent the same absolute time assert dt_rt.replace(tzinfo=None) == dt.replace(tzinfo=None) # And the same wall time For all valid values of `dt`, `args` and `kwargs`. A corollary of the `dt_rt == dt` invariant is that you can perfectly recreate the original `datetime` with the following additional step: dt_rt = dt_rt if dt.tzinfo is None else dt_rt.astimezone(dt.tzinfo) There is no way for us to guarantee that `dt_rt.tzinfo == dt.tzinfo` or that `dt_rt.tzinfo is dt.tzinfo`, because `isoformat()` is slightly lossy (it loses the political zone), but this is not an issue because lossless round trips just require you to serialize the political zone, which is generally simple enough. On 12/06/2017 07:54 PM, Barry Scott wrote:

...

On 26 Oct 2017, at 17:45, Chris Barker <chris.barker@noaa.gov> wrote:

This is a key point that I hope is obvious:

If an ISO string has NO offset or timezone indicator, then a naive datetime should be created.

(I say, I "hope" it's obvious, because the numpy datetime64 implementation initially (and for years) would apply the machine local timezone to a bare iso string -- which was a f-ing nightmare!)

I hope the other obvious thing is that if there is a offset then a datetime that is *not* naive can be created as it describes an unambiguous point in time. We just cannot know what political timezone to choose. I'd guess that it should use the UTC timezone in that case.

Barry

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/paul%40ganssle.io

And I'm sorry, I got a bit lost in the PR, but you are attaching an "offset" tzinfo, when parsing an iso string that has one, yes?

Yes, a fixed offset time zone (since the original zone information is lost): >>> from dateutil import tz >>> from datetime import datetime >>> datetime(2014, 12, 11, 9, 30, tzinfo=tz.gettz('US/Eastern')) datetime.datetime(2014, 12, 11, 9, 30, tzinfo=tzfile('/usr/share/zoneinfo/US/Eastern')) >>> datetime(2014, 12, 11, 9, 30, tzinfo=tz.gettz('US/Eastern')).isoformat() '2014-12-11T09:30:00-05:00' >>> datetime.fromisoformat('2014-12-11T09:30:00-05:00') datetime.datetime(2014, 12, 11, 9, 30, tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=68400)))

I fully agree that that's the MVP -- but is it that hard to parse arbitrary ISO8601 strings in once you've gotten this far? It's a bit uglier than I'd like, but not THAT bad a spec.

No, and in fact this PR is adapted from a *more general* ISO-8601 parser that I wrote (which is now merged into master on python-dateutil). In the CPython PR I deliberately limited it to be the inverse of `isoformat()` for two major reasons: 1. It allows us to get something out there that everyone can agree on - not only would we have to agree on whether to support arcane ISO8601 formats like YYYY-Www-D, but we also have to then discuss whether we want to be strict and disallow YYYYMM like ISO-8601 does, do we want fractional minute support? What about different variations (we're already supporting replacing T with any character in `.isoformat()` and outputting time zones in the form hh:mm:ss, so what other non-compliant variations do we want to add... and then maintain? We can have these discussions later if we want, but we might as well start with the part everyone can agree on - if it comes out of `isoformat()` it should be able to go back in througuh `fromisoformat()`. 2. It makes it *much* easier to understand what formats are supported. You can say, "This function is for reading in dates serialized with `.isoformat()`", you *immediately* know how to create compliant dates. Not to mention, the specific of formats emitted by `isoformat()` can be written very cleanly as: YYYY-MM-DD[*[HH[:MM[:SS[.mmm[mmm]]]]][+HH:MM]] (where * means any character). ISO 8601 supports YYYY-MM-DD and YYYYMMDD but not YYYY-MMDD or YYYYMM-DD So, basically, it's not that it's amazingly hard to write a fully-featured ISO-8601, it's more that it doesn't seem like a great match for the problem this is intended to solve at this point. Best, Paul On 12/07/2017 08:12 PM, Chris Barker wrote:

...

Here is the PR I've submitted:

https://github.com/python/cpython/pull/4699

The contract that I'm supporting (and, I think it can be argued, the only reasonable contract in the intial implementation) is the following:

dtstr = dt.isoformat(*args, **kwargs) dt_rt = datetime.fromisoformat(dtstr) assert dt_rt == dt # The two points represent the same absolute time assert dt_rt.replace(tzinfo=None) == dt.replace(tzinfo=None) # And the same wall time

that looks good.

I see this in the comments in the PR:

""" This does not support parsing arbitrary ISO 8601 strings - it is only intended as the inverse operation of :meth:`datetime.isoformat` """

what ISO8601 compatible features are not supported?

-CHB

Guess the argument for limiting what it accepts would be that every funky variation will need to be supported until the endtimes, even those of little use or utility. On the other hand, it might be good to keep the two implementations the same for consistency reasons. Thanks either way, -Mike On 2017-12-07 17:57, Chris Barker - NOAA Federal wrote:

-----Original Message----- From: Python-Dev [mailto:python-dev-bounces+tritium- list=sdamon.com@python.org] On Behalf Of Alexander Belopolsky Sent: Tuesday, October 24, 2017 5:54 PM To: Chris Barker <chris.barker@noaa.gov> Cc: Python-Dev <python-dev@python.org> Subject: Re: [Python-Dev] iso8601 parsing

On Tue, Oct 24, 2017 at 5:26 PM, Chris Barker <chris.barker@noaa.gov> wrote:

...

On Mon, Oct 23, 2017 at 5:33 PM, Hasan Diwan <hasan.diwan@gmail.com> wrote:

...

can anyone argue that it's not a good idea for datetime ot be able to read the iso format it puts out?

No, but the last time I suggested that that datetime types should satisfy the same invariants as numbers, namely T(repr(x)) == x, the idea was met will silence. I, on the other hand, am not very enthusiastic about named constructors such as date.isoparse(). Compared with date(s:str), this is one more method name to remember, plus the potential for abuse as an instance method. What is d.isoparse('2017-11-24')?

Datetime.datetime.fromiso() (classmethod) is much more in keeping with the rest of the datetime api - in fact, I have tried calling that method more than once, before remembering datetime *doesn't* have that classmethod. Making it a classmethod solves any concerns about calling it as an instance method (the same way d.now() and d.strptime() just create and return a new datetime objects, not mutates the current). In fact, looking at the docs, most of the methods are classmethods, so an additional classmethod is fitting. I really do not like the idea of making the first positional argument of the datetime constructor int or str. What happens when you pass a string for the first argument and ints for subsequent arguments? You would have to raise a typeerror or valueerror. I don't like that API design - it means the type of the first argument changes the semantic meaning of subsequent arguments, and that just adds a level of confusion to any api. You might be able to get away with that in third party code, but this is the standard library, and this is the time manipulation module in the standard library - you have to assume that this is one of the first modules a new user uses, we have to keep the api sane. The only way I can think of keeping the api sane and still pass an iso string to the constructor is to pass It as a keyword argument - and at that point you have to remember the argument name anyways, so you might as well make it a classmethod to match everything else in the library. $0.02

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium- list%40sdamon.com

-----Original Message----- From: Alexander Belopolsky [mailto:alexander.belopolsky@gmail.com] Sent: Wednesday, October 25, 2017 12:07 PM To: Alex Walters <tritium-list@sdamon.com> Cc: Chris Barker <chris.barker@noaa.gov>; Python-Dev <python- dev@python.org> Subject: Re: [Python-Dev] iso8601 parsing

...

On Oct 25, 2017, at 11:45 AM, Alex Walters <tritium-list@sdamon.com> wrote:

it means the type of the first argument changes the semantic meaning of subsequent arguments, and that just adds a level of confusion to any api.

No, it does not. Passing a string a the first of three arguments will still be a type error.

And that is a confusing api. The problem has already been solved by classmethod alternate constructors - they are already used widely in the datetime api. NOT using classmethod constructors is new and confusing for the SINGLE use case of parsing iso formatted dates and times. Why is that special? Why isn't ordinal time special to get into __init__?

The basics should be possible already with issue31800 <https://bugs.python.org/issue31800>, that said the issue you reference is to get a single function to parse it (without having to put the whole format), which would be neat. I believe Paul Ganssle is planning on adding it to dateutil as well: https://github.com/dateutil/dateutil/pull/489/files On 28 November 2017 at 19:51, Mike Miller <python-dev@mgmiller.net> wrote:

This may have gotten bogged down again. Could we get the output of datetime.isoformat() parsed at a minimum? Perfection is not required.

Looks like there is a patch or two and test cases on the bug.

-Mike

Could anyone put this five year-old bug about parsing iso8601 format

...

date-times on the front burner?

http://bugs.python.org/issue15873

In the comments there's a lot of hand-wringing about different variations that bogged it down, but right now I only need it to handle the output of datetime.isoformat():

>>> dt.isoformat() '2017-10-20T08:20:08.986166+00:00'

Perhaps if we could get that minimum first step in, it could be iterated on and made more lenient in the future.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mariocj89 %40gmail.com

I think the latest version can now strptime offsets of the form ±HH:MM with %z, so there's no longer anything blocking you from parsing from all isoformat() outputs with strptime, provided you know which one you need.

Or just punt and install arrow:

...

...

import arrow arrow.get('2017-10-20T08:20:08.986166+00:00') <Arrow [2017-10-20T08:20:08.986166+00:00]> arrow.get('2017-10-20T08:20:08.986166+00:00').datetime datetime.datetime(2017, 10, 20, 8, 20, 8, 986166, tzinfo=tzoffset(None, 0))

Skip

It's got its own little parsing language, different than the usual strftime/strptime format scheme, more like what you might see in Excel. I never worried too much about the speed of dateutil.parser.parse() unless I was calling it in an inner loop, but arrow.get() seems to be a fair bit faster than dateutil.parser.parse. This makes sense, as the latter tries to figure out what you've given it (you never give it a format string), while in the absence of a format string, arrow.get assumes you have an ISO-8601 date/time, with only a few small variations allowed. Skip On Tue, Nov 28, 2017 at 2:52 PM, Paul G <paul@ganssle.io> wrote:

IIRC, arrow usually calls dateutil to parse dates anyway, and there are many other, lighter dependencies that will parse an ISO 8601 date quickly into a datetime.datetime object.

I still think it's reasonable for the .isoformat() operation to have an inverse operation in the standard library.

On November 28, 2017 3:45:41 PM EST, Skip Montanaro < skip.montanaro@gmail.com> wrote:

...

I think the latest version can now strptime offsets of the form ±HH:MM with

...

%z, so there's no longer anything blocking you from parsing from all isoformat() outputs with strptime, provided you know which one you need.

Or just punt and install arrow:

import arrow

...

...

...

arrow.get('2017-10-20T08:20:08.986166+00:00')

<Arrow [2017-10-20T08:20:08.986166+00:00]>

...

arrow.get('2017-10-20T08:20:08.986166+00:00').datetime

...

...

datetime.datetime(2017, 10, 20, 8, 20, 8, 986166, tzinfo=tzoffset(None, 0))

Skip

On Wed, Nov 29, 2017 at 10:05 AM, Mike Miller <python-dev@mgmiller.net> wrote:

This thread isn't about the numerous third-party solutions that are a pip command away. But rather getting a minimal return parser to handle datetime.isoformat() into the std library.

It's been needed for years,

indeed what is the holdup? I don't recall anyone saying it was a bad idea in the last discussion. Do we just need an implementation? Is the one in the Bug Report not up to snuff? If not, then what's wrong with it? This is just not that hard a problem to solve. -CHB

and hopefully someone can squeeze it into 3.7 before its too late. (It takes years for a new version to trickle down to Linux dists.)

-Mike

On 2017-11-28 13:09, Skip Montanaro wrote:

...

It's got its own little parsing language, different than the usual

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris. barker%40noaa.gov

-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

There were discussions about having it a function, making the constructor of datetime accept a string(this was strongly rejected), having a static funcion in datetime, etc... and there was no real agreement. If the agreement is that we want a funcion to be able to parse it I am sure Paul G will be kind to do it (he told me not long ago he was thinking on sending a PR for it). If he is busy I am happy to chip in time this weekend. All I wanted when I sent https://bugs.python.org/issue31800 was actually to be able to parse isoformat datetime ^^. Thu, 30 Nov 2017 at 00:09, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:

On Wed, Nov 29, 2017 at 6:42 PM, Chris Barker <chris.barker@noaa.gov> wrote:

...

indeed what is the holdup? I don't recall anyone saying it was a bad idea in the last discussion.

Do we just need an implementation?

Is the one in the Bug Report not up to snuff? If not, then what's wrong with it? This is just not that hard a problem to solve.

See my comment from over a year ago: < https://bugs.python.org/issue15873#msg273609>. The proposed patch did not have a C implementation, but we can use the same approach as with strptime and call Python code from C. If users will start complaining about performance, we can speed it up in later releases. Also the new method needs to be documented. Overall, it does not seem to require more than an hour of work from a motivated developer, but the people who contributed to the issue in the past seem to have lost their interest. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mariocj89%40gmail.com

I can write at least a pure Python implementation in the next few days, if not a full C implementation. Shouldn't be too hard since I've got a few different Cython implementations sitting around anyway. On November 29, 2017 7:06:58 PM EST, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:

On Wed, Nov 29, 2017 at 6:42 PM, Chris Barker <chris.barker@noaa.gov> wrote:

...

indeed what is the holdup? I don't recall anyone saying it was a bad

idea

...

in the last discussion.

Do we just need an implementation?

Is the one in the Bug Report not up to snuff? If not, then what's wrong with it? This is just not that hard a problem to solve.

See my comment from over a year ago: < https://bugs.python.org/issue15873#msg273609>. The proposed patch did not have a C implementation, but we can use the same approach as with strptime and call Python code from C. If users will start complaining about performance, we can speed it up in later releases. Also the new method needs to be documented. Overall, it does not seem to require more than an hour of work from a motivated developer, but the people who contributed to the issue in the past seem to have lost their interest.

On Wed, Nov 29, 2017 at 4:19 PM, Paul G <paul@ganssle.io> wrote:

I can write at least a pure Python implementation in the next few days, if not a full C implementation. Shouldn't be too hard since I've got a few different Cython implementations sitting around anyway.

Thanks! -CHB

On November 29, 2017 7:06:58 PM EST, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:

...

On Wed, Nov 29, 2017 at 6:42 PM, Chris Barker <chris.barker@noaa.gov> wrote:

...

indeed what is the holdup? I don't recall anyone saying it was a bad idea in the last discussion.

Do we just need an implementation?

Is the one in the Bug Report not up to snuff? If not, then what's wrong with it? This is just not that hard a problem to solve.

See my comment from over a year ago: <https://bugs.python.org/ issue15873#msg273609>. The proposed patch did not have a C implementation, but we can use the same approach as with strptime and call Python code from C. If users will start complaining about performance, we can speed it up in later releases. Also the new method needs to be documented. Overall, it does not seem to require more than an hour of work from a motivated developer, but the people who contributed to the issue in the past seem to have lost their interest.

-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

is there a strict deadline here if we want this for Python 3.7?

The deadline for the new features is the date of the first beta currently scheduled for 2018-01-29, but if you can get this in before the last alpha (2018-01-08) it will be best. See PEP 537 (https://www.python.org/dev/peps/pep-0537) for details and updates.