
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

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
-- 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 Tue, Oct 24, 2017 at 5:26 PM, Chris Barker <chris.barker@noaa.gov> 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')?

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.

+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:
-- 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 Wed, Oct 25, 2017 at 5:30 PM, Chris Barker <chris.barker@noaa.gov> wrote:
Let's get passed the bike shedding and make this work!
Sure. Submitting a pull request for <https://bugs.python.org/issue15873> would be a good start.

On 26 October 2017 at 07:30, Chris Barker <chris.barker@noaa.gov> wrote:
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 16:32, Alexander Belopolsky wrote:
Generic code that uses a Callable[[str], ...] instead of a type works fine with a class method. column1.parser = int column2.parser = float column3.parser = datetime.parse_iso column4.parser = json.loads It is *very slightly* more complex than a model that needs the type also for some reason and has the type pull double duty as the parser... but why do that?

On Wed, Oct 25, 2017 at 04:32:39PM -0400, Alexander Belopolsky wrote:
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:
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

I think this ship has long sailed. Sorry Alexander, but I see a new class method in your future. -- --Guido van Rossum (python.org/~guido)

On Wednesday, October 25, 2017, Chris Barker <chris.barker@noaa.gov> wrote:
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 10:37 PM, Wes Turner <wes.turner@gmail.com> wrote:
What would you call the str argument? Does it accept strptime args or only ISO8601?
There'd be no reason to accept a format. That wouldn't make sense. A .fromiso(s:str) should only accept an ISO 8601 string, though I'd advocate tolerating both space and "T".
Would all of that string parsing logic be a performance regression from the current constructor? Does it accept None or empty string?
It's an alternate constructor, so should not impact the existing constructor (though it could employ the existing constructor to get work done). It should not accept anything but a valid ISO 8601 string.
Should the date time constructor support nanos= (just like time_ns())?
No. It should support exactly up to 6 decimal digits to populate the microsecond field.
ENH: Add nanosecond support to the time and datetime constructors
This should be left for a separate change, if we determine it should be implemented for the datetime and timedelta types. -Fred -- Fred L. Drake, Jr. <fred at fdrake.net> "A storm broke loose in my mind." --Albert Einstein

On Wed, Oct 25, 2017 at 7:37 PM, Wes Turner <wes.turner@gmail.com> wrote:
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
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!)
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))
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

From: Python-Dev [mailto:python-dev-bounces+tritium-list=sdamon.com@python.org] On Behalf Of Chris Barker Sent: Thursday, October 26, 2017 12:46 PM To: Wes Turner <wes.turner@gmail.com> Cc: Python-Dev <python-dev@python.org> Subject: Re: [Python-Dev] iso8601 parsing
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 :-) )
US Central Standard, Mountain Daylight. (Eastern is -5/-4DST)

On Thursday, October 26, 2017, Chris Barker <chris.barker@noaa.gov> wrote:
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.
If an ISO string has NO offset or timezone indicator, then a naive datetime should be created.
astropy.time.Time supports numpy.
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).
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).

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

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 Wed, Dec 6, 2017 at 3:07 PM, Paul Ganssle <pganssle@gmail.com> wrote:
that looks good. 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? 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` """ 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. what ISO8601 compatible features are not supported? -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

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)))
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:
what ISO8601 compatible features are not supported?
-CHB

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, I don’t know — would anyone complain about it supporting too arcane a format? Also — “most ISO compliant “ date time strings would get us a long way. but we also have to then discuss whether we want to be strict and disallow YYYYMM like ISO-8601 does, Well, I think disallowing something has little utility - we really don’t want this to be a validator. 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.. Wait — does datetime.isoformat() put out non-compliant strings? Anyway, supporting all of what .isoformat() puts out, plus Most of iso8601 would be a great start. - if it comes out of `isoformat()` it should be able to go back in througuh `fromisoformat()`. Yup. But had anyone raised objections to it being more flexible? 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. We could still document that as the preferred form. You’re writing the code, and I don’t have time to help, so by all means do what you think is best. But if you’ve got code that’s more flexible, I can’t imagine anyone complaining about a more flexible parser. Though I have a limited imagination about such things. But I hope it will at least accept both with and without the T. Thanks for working on this. -Chris 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:

On Dec 7, 2017, at 7:52 PM, Mike Miller <python-dev@mgmiller.net> wrote: 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. I suppose so, but not that hard once implemented and tests in place. How about this for a “practicality beats purity” approach: .fromiso() will parse the most commonly used iso8601 compliant date time strings. It is guaranteed to properly parse the output of .isoformat() It is Not a validator — it may except non-iso compliant strings, and may give surprising results when passed such. <end/> In any case, I sure hope it will accept iso strings both with and without the “T”. But again: Paul, do whatever you think is best. -CHB 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: _______________________________________________ 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

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

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:

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. I think a from_isoformat() like method that *only* supports isoformat outputs is a fine idea, though, with a fairly obvious interface. I'd be happy to take a crack at it (I've been working on the somewhat harder problem of an iso8601 compliant parser for dateutil, so this is fresh in my mind). On November 28, 2017 2:51:14 PM EST, Mike Miller <python-dev@mgmiller.net> 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:

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:

Hi, 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, 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

On Wed, Nov 29, 2017 at 10:05 AM, Mike Miller <python-dev@mgmiller.net> 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. -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 Wed, Nov 29, 2017 at 6:42 PM, Chris Barker <chris.barker@noaa.gov> wrote:
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.

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:

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:

Yeah! I'm available for writing docs and testing it if needed. Performance is not a big concern in this first version, unless you've already written most of it. If it is a concern for others then the third-party modules will still be available as well. -Mike On 2017-11-29 16:19, Paul G wrote:

On Wed, Nov 29, 2017 at 4:19 PM, Paul G <paul@ganssle.io> wrote:
Thanks! -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

As an update, I have the C version done and basically tested as an extension (I "cheated" on the tests by using hypothesis, so I still need to write unittest-style tests), just writing the Python version with tests now. I know there is a feature freeze coming in soon, is there a strict deadline here if we want this for Python 3.7? Best, Paul On 12/01/2017 12:47 PM, Chris Barker wrote:

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.

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
-- 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 Tue, Oct 24, 2017 at 5:26 PM, Chris Barker <chris.barker@noaa.gov> 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')?

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.

+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:
-- 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 Wed, Oct 25, 2017 at 5:30 PM, Chris Barker <chris.barker@noaa.gov> wrote:
Let's get passed the bike shedding and make this work!
Sure. Submitting a pull request for <https://bugs.python.org/issue15873> would be a good start.

On 26 October 2017 at 07:30, Chris Barker <chris.barker@noaa.gov> wrote:
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 16:32, Alexander Belopolsky wrote:
Generic code that uses a Callable[[str], ...] instead of a type works fine with a class method. column1.parser = int column2.parser = float column3.parser = datetime.parse_iso column4.parser = json.loads It is *very slightly* more complex than a model that needs the type also for some reason and has the type pull double duty as the parser... but why do that?

On Wed, Oct 25, 2017 at 04:32:39PM -0400, Alexander Belopolsky wrote:
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:
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

I think this ship has long sailed. Sorry Alexander, but I see a new class method in your future. -- --Guido van Rossum (python.org/~guido)

On Wednesday, October 25, 2017, Chris Barker <chris.barker@noaa.gov> wrote:
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 10:37 PM, Wes Turner <wes.turner@gmail.com> wrote:
What would you call the str argument? Does it accept strptime args or only ISO8601?
There'd be no reason to accept a format. That wouldn't make sense. A .fromiso(s:str) should only accept an ISO 8601 string, though I'd advocate tolerating both space and "T".
Would all of that string parsing logic be a performance regression from the current constructor? Does it accept None or empty string?
It's an alternate constructor, so should not impact the existing constructor (though it could employ the existing constructor to get work done). It should not accept anything but a valid ISO 8601 string.
Should the date time constructor support nanos= (just like time_ns())?
No. It should support exactly up to 6 decimal digits to populate the microsecond field.
ENH: Add nanosecond support to the time and datetime constructors
This should be left for a separate change, if we determine it should be implemented for the datetime and timedelta types. -Fred -- Fred L. Drake, Jr. <fred at fdrake.net> "A storm broke loose in my mind." --Albert Einstein

On Wed, Oct 25, 2017 at 7:37 PM, Wes Turner <wes.turner@gmail.com> wrote:
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
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!)
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))
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

From: Python-Dev [mailto:python-dev-bounces+tritium-list=sdamon.com@python.org] On Behalf Of Chris Barker Sent: Thursday, October 26, 2017 12:46 PM To: Wes Turner <wes.turner@gmail.com> Cc: Python-Dev <python-dev@python.org> Subject: Re: [Python-Dev] iso8601 parsing
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 :-) )
US Central Standard, Mountain Daylight. (Eastern is -5/-4DST)

On Thursday, October 26, 2017, Chris Barker <chris.barker@noaa.gov> wrote:
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.
If an ISO string has NO offset or timezone indicator, then a naive datetime should be created.
astropy.time.Time supports numpy.
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).
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).

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

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 Wed, Dec 6, 2017 at 3:07 PM, Paul Ganssle <pganssle@gmail.com> wrote:
that looks good. 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? 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` """ 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. what ISO8601 compatible features are not supported? -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

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)))
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:
what ISO8601 compatible features are not supported?
-CHB

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, I don’t know — would anyone complain about it supporting too arcane a format? Also — “most ISO compliant “ date time strings would get us a long way. but we also have to then discuss whether we want to be strict and disallow YYYYMM like ISO-8601 does, Well, I think disallowing something has little utility - we really don’t want this to be a validator. 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.. Wait — does datetime.isoformat() put out non-compliant strings? Anyway, supporting all of what .isoformat() puts out, plus Most of iso8601 would be a great start. - if it comes out of `isoformat()` it should be able to go back in througuh `fromisoformat()`. Yup. But had anyone raised objections to it being more flexible? 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. We could still document that as the preferred form. You’re writing the code, and I don’t have time to help, so by all means do what you think is best. But if you’ve got code that’s more flexible, I can’t imagine anyone complaining about a more flexible parser. Though I have a limited imagination about such things. But I hope it will at least accept both with and without the T. Thanks for working on this. -Chris 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:

On Dec 7, 2017, at 7:52 PM, Mike Miller <python-dev@mgmiller.net> wrote: 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. I suppose so, but not that hard once implemented and tests in place. How about this for a “practicality beats purity” approach: .fromiso() will parse the most commonly used iso8601 compliant date time strings. It is guaranteed to properly parse the output of .isoformat() It is Not a validator — it may except non-iso compliant strings, and may give surprising results when passed such. <end/> In any case, I sure hope it will accept iso strings both with and without the “T”. But again: Paul, do whatever you think is best. -CHB 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: _______________________________________________ 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

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

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:

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. I think a from_isoformat() like method that *only* supports isoformat outputs is a fine idea, though, with a fairly obvious interface. I'd be happy to take a crack at it (I've been working on the somewhat harder problem of an iso8601 compliant parser for dateutil, so this is fresh in my mind). On November 28, 2017 2:51:14 PM EST, Mike Miller <python-dev@mgmiller.net> 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:

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:

Hi, 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, 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

On Wed, Nov 29, 2017 at 10:05 AM, Mike Miller <python-dev@mgmiller.net> 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. -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 Wed, Nov 29, 2017 at 6:42 PM, Chris Barker <chris.barker@noaa.gov> wrote:
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.

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:

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:

Yeah! I'm available for writing docs and testing it if needed. Performance is not a big concern in this first version, unless you've already written most of it. If it is a concern for others then the third-party modules will still be available as well. -Mike On 2017-11-29 16:19, Paul G wrote:

On Wed, Nov 29, 2017 at 4:19 PM, Paul G <paul@ganssle.io> wrote:
Thanks! -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

As an update, I have the C version done and basically tested as an extension (I "cheated" on the tests by using hypothesis, so I still need to write unittest-style tests), just writing the Python version with tests now. I know there is a feature freeze coming in soon, is there a strict deadline here if we want this for Python 3.7? Best, Paul On 12/01/2017 12:47 PM, Chris Barker wrote:

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.
participants (18)
-
Alex Walters
-
Alexander Belopolsky
-
Barry Scott
-
Chris Barker
-
Chris Barker - NOAA Federal
-
Elvis Pranskevichus
-
Fred Drake
-
Guido van Rossum
-
Hasan Diwan
-
Mario Corchero
-
Mike Miller
-
Nick Coghlan
-
Paul G
-
Paul Ganssle
-
Random832
-
Skip Montanaro
-
Steven D'Aprano
-
Wes Turner