bpo-15873: Implement [date][time].fromisoformat #4699

pganssle · 2017-12-04T17:34:07Z

Per discussion on the python-dev mailing list, this is a C implementation of fromisoformat as alternate constructors for datetime, date and time, resolving this issue.

If it is deemed desirable, it can be extended later to cover all ISO-8601 datetime strings, but I believe the consensus so far is to have a minimum implementation that only covers the outputs of datetime.isoformat().

One thing I'd like to call attention to is that my profiling seems to indicate that in the common case (i.e. not calling this from a subclass), using the C API directly is much faster than going through PyObject_CallFunction.

Here is a profiling script:

from datetime import datetime
from datetime import timezone, timedelta
from timeit import default_timer as timer

N = 100000
tzi = timezone(timedelta(hours=4))
tzi = None
comps = (2014, 3, 25, 4, 17, 30, 204300, tzi)
dt = datetime(*comps)

s = timer()
for i in range(N):
    dt_c = datetime(2014, 3, 25, 4, 17, 30, 241300, tzinfo=tzi)
e = timer()

tt = 1000000000 * (e - s) / N
dtstr = dt.isoformat()

s = timer()
for i in range(N):
    dt_fi = datetime.fromisoformat(dtstr)
e = timer()
tt2 = 1000000000 * (e - s) / N

print('datetime constructor: {:0.1f}ns'.format(tt))
print('fromisoformat:       {:0.1f}ns'.format(tt2))

Result on my laptop:

(tzi is None):
datetime constructor: 2294.1ns
fromisoformat:       944.5ns

(tzi = timezone(timedelta(hours=4)))
datetime constructor: 2229.1ns
fromisoformat:       1400.5ns

If there's no particularly pressing reason why all the other alternate constructors universally go through the main constructor call, I could write a small function or macro that would take the fast path if available and use it for all the alternate constructors.

CC @abalkin @mariocj89

https://bugs.python.org/issue15873

pganssle · 2017-12-04T17:48:08Z

One other thing I'll note - the pure python implementation here is at least partially optimized for speed. There is a fairly trivial implementation that looks, more or less, like this:

from datetime import datetime 

_base_strptimes = {
    10: '%Y-%m-%d',
    13: '%Y-%m-%dT%H',
    16: '%Y-%m-%dT%H:%M',
    19: '%Y-%m-%dT%H:%M:%S',
    23: '%Y-%m-%dT%H:%M:%S.%f',
    26: '%Y-%m-%dT%H:%M:%S.%f'
}

def from_strptime(dtstr):
    if not isinstance(dtstr, str):
        raise TypeError('isoformat takes str')

    if len(dtstr) >= 19 and dtstr[-6] in '+-':
        fmt = _base_strptimes[len(dtstr) - 6] + '%z'
    else:
        fmt = _base_strptimes[len(dtstr)]

    return datetime.strptime(dtstr, fmt)

This will work, but strptime is actually fairly slow, and in my benchmarks the pure python implementation here is twice as fast as the strptime-based method.

abalkin · 2017-12-04T19:11:47Z

Modules/_datetimemodule.c

+/* ---------------------------------------------------------------------------
+ * String parsing utilities and helper functions
+ */
+static inline unsigned int to_int(char ptr)


I don't think "static inline" is interpreted differently from "static" by any relevant compilers. AFAIK, we don't use "static inline" elsewhere in CPython code. Please just use "static".

Not a problem. I translated these from macros in my original code so it seemed like inline was appropriate at the time, but I don't have strong opinions in this regard.

abalkin · 2017-12-04T19:15:58Z

Modules/_datetimemodule.c

+/* ---------------------------------------------------------------------------
+ * String parsing utilities and helper functions
+ */
+static inline unsigned int to_int(char ptr)


The name "ptr" is usually used for pointers. Please change "ptr" to "ch" here. On the other hand, I don't think to_int(ch) is clearer than ch - '-'. Call it digit_to_int or just use the expanded expression.

Yeah, this is my mistake. As I mentioned in another comment, I translated this from a macro where it was actually manipulating the pointer directly. When I translated it into a function the variable name didn't get fixed.

abalkin · 2017-12-04T19:20:07Z

Modules/_datetimemodule.c

+{
+    for (size_t i = 0; i < num_digits; ++i) {
+        int tmp = to_int(*(ptr++));
+        if (!is_digit(tmp)) { return NULL; }


I would just use ANSI C isdigit on the character.

I can actually just replace this with tmp <= 9, I think isdigit might be overkill. This is_digit relies on the specific way that to_int works - and I only used this particular combination because in early Cython-based tests my profiling indicated that atoi was a slow step.

bedevere-bot · 2017-12-04T19:21:28Z

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

vadmium · 2017-12-04T21:54:43Z

Doc/library/datetime.rst

+  Return a :class:`datetime` corresponding to a *date_string* in one of the
+  ISO 8601 formats emitted by :meth:`datetime.isoformat`. Specifically, this function
+  supports strings in the format(s) ``YYYY-MM-DD[*[HH[:MM:[SS[.mmm[mmm]]]]][+HH:MM]]``,
+  where ``*`` can match any single character.


Should the colon after :MM be optional?

vadmium · 2017-12-04T21:58:19Z

Doc/library/datetime.rst

@@ -1486,6 +1515,23 @@ In boolean contexts, a :class:`.time` object is always considered to be true.
   error-prone and has been removed in Python 3.5.  See :issue:`13936` for full
   details.

+
+Other constructors:


Singular: constructor

vadmium · 2017-12-04T22:16:19Z

Doc/library/datetime.rst

+
+  Return a :class:`time` corresponding to a *time_string* in one of the ISO 8601
+  formats emitted by :meth:`time.isoformat`. Specifically, this function supports
+  strings in the format(s) ``HH[:MM:[SS[.mmm[mmm[+HH:MM]]]]]]``.


I think you need to parse the time zone without :MM:SS.mmmmmm, e.g. 09:12:32+11:00. See your datetime.datetime format.

vadmium · 2017-12-04T22:21:40Z

Lib/test/datetimetester.py

+
+        dt_rt = DateSubclass.fromisoformat(dt.isoformat())
+
+        self.assertIsInstance(dt_rt, DateSubclass)


If it is worth testing this, maybe it is worth documenting it?

That can be done. I considered doing it but decided against it because while this behavior is both true and tested for all the constructors in datetime, it's not documented for any of them as far as I've seen. I can document it in just this one, or I can document it in all of them, I'm not picky.

vadmium · 2017-12-04T22:26:10Z

Lib/test/datetimetester.py

+               for tzi in tzinfos]
+
+        for dt in dts:
+            for sep in separators:


6 × 5 × 8 × 5 is 1200 tests. Perhaps just one test for each case (6 + 5 + 8 + 5) instead?

This is a good point. I translated these tests from hypothesis where the space is sampled sparsely. I think I can refactor out at least the separator dimension and probably reduce the dimensionality of some of the remaining tests. I'll look at it tomorrow.

I refactored out the separator tests and reduced some of the space that is sampled. I think most of the variation in the date and time portions separately is covered by the respective date and time parser functions. I think we're down to ~160 tests.

pganssle · 2017-12-05T01:33:47Z

Lib/datetime.py

+        if next_char != ':':
+            raise ValueError('Invalid time separator')
+        if pos >= len_str:
+            break


In retrospect, I think maybe it's logically impossible to hit this branch, since we only get here if tstr[pos:pos+1] == ':'. I'll remove this in the next iteration.

pganssle · 2017-12-05T01:34:43Z

Lib/datetime.py

+
+        time_comps[-1] = timezone(td)
+
+    if pos < len_str:


I guess this check is redundant with the (len_str - pos) != 6 check above.

pganssle · 2017-12-05T02:06:47Z

@abalkin @vadmium I think I've fixed all the concerns raised so far - some good catches in there. There are three documentation-related concerns:

Per @vadmium, although there are tests that ensure that this and other alternate constructors have heritable behavior (e.g. MyDateTimeClass.fromisoformat(dt.isoformat()) should return a MyDateTimeClass), this is not explicitly documented. I think we could add a note at the class level like, "Alternate constructors called on datetime subclasses will return an instance of the subclass" - though to some extent that feels like it's already part of the implicit contract (considering it's a classmethod and not a staticmethod).
I do not explicitly mention the fact that +00:00 and -00:00 will attach timezone.utc instead of timezone(timedelta(0)). I think this is almost certainly the correct behavior, but it may be somewhat surprising and I could easily see dropping this special-casing of the zero-offset zone. Presumably I should at least document this?
Per some discussions on the issue, this is explicitly the "minimum viable feature set". Currently it's true that datetime.fromisoformat will parse a string if and only if that string can be generated by datetime.isoformat. Do we want to put something in the documentation equivalent to "don't rely on this to validate whether or not something came from datetime.isoformat, because we're only agreeing to guarantee that it will parse anything that datetime.isoformat can generate, and we reserve the right to accept other formats"?

pganssle · 2017-12-05T02:21:06Z

Lib/datetime.py

+    def fromisoformat(cls, time_string):
+        """Construct a time from the output of isoformat()."""
+        if not isinstance(time_string, str):
+            raise TypeError('fromisoformat: argument must be str')


I'm not really sure why this is not getting hit by the test suite. test_fromisoformat_fails_typeerror is designed explicitly to hit this condition. Anyone have an idea why it's getting missed?

vadmium · 2017-12-05T03:38:03Z

Lib/test/datetimetester.py

+
+        for bad_type in bad_types:
+            with self.assertRaises(TypeError):
+                self.theclass(bad_type)


self.theclass.fromisoformat(bad_type)

A-ha! Thanks!

abalkin · 2017-12-05T20:51:00Z

Modules/_datetimemodule.c

+ * String parsing utilities and helper functions
+ */
+
+static const char* parse_digits(const char* ptr, int* var,


Sorry I missed this on the first review. PEP 7 calls for "function name in column 1". See PEP 7.

abalkin · 2017-12-05T20:57:01Z

Modules/_datetimemodule.c

+static const char* parse_digits(const char* ptr, int* var,
+                                       size_t num_digits)
+{
+    for (size_t i = 0; i < num_digits; ++i) {


C99 - style for loops are not specifically mentioned in the "C dialect" section of PEP 7. I personally like this style, so if this compiles without warnings, we may leave it.

abalkin · 2017-12-05T21:01:48Z

Modules/_datetimemodule.c

+}
+
+// Macro that short-circuits to timezone parsing
+#define PARSE_ISOFORMAT_ADVANCE_TIME_SEP(SEP) {       \


Please alight the .

abalkin · 2017-12-05T21:06:03Z

Modules/_datetimemodule.c

+            return -5;
+    }
+
+parse_timezone:;


No need for a ; after the label.

Unfortunately yes, there is. It's a syntax error without the ;, because the following line is a variable declaration, not a statement, and the label is intended to be a labeled statement (Ref StackOverflow, citing section 6.8.1).

That said, there's no particular reason why those variables can't be declared at the top of the function (before the first call to PARSE_ISOFORMAT_ADVANCE_TIME_SEP). Would you prefer that?

abalkin · 2017-12-05T21:09:29Z

Modules/_datetimemodule.c

+    */
+    const char *p = dtstr;
+    p = parse_digits(p, year, 4);
+    if (NULL == p) { return -1; }


Please use PEP 7 code layout.

mariocj89 · 2017-12-06T12:28:51Z

To fully support isoformat output you also need to parse seconds on the timezone:

datetime.datetime.now(datetime.timezone(datetime.timedelta(seconds=30))).isoformat()
'2017-12-06T12:28:38.567161+00:00:30'

pganssle · 2017-12-06T23:07:54Z

@mariocj89 Thanks for the catch. The PR is updated with tests and implementation. Didn't realize that second precision was allowed in isoformat() in Python 3.7.

pganssle · 2017-12-07T16:04:39Z

Modules/_datetimemodule.c

+    }
+
+    PyObject *result;
+    if (PyDate_CheckExact(cls)) {


This check is actually wrong, so this branch is never reached. The correct code is:

if ( (PyTypeObject*)cls == &PyDateTime_DateType ) {

abalkin · 2017-12-07T19:50:38Z

Didn't realize that second precision was allowed in isoformat() in Python 3.7.

Moreover, the sub-second precision is now allowed as well:

>>> from datetime import *
>>> import random
>>> datetime.now(timezone(timedelta(hours=24*random.random()))).isoformat()
'2017-12-08T11:34:30.238049+15:47:34.297540'

The good news is that you should be able to reuse the time fields parser logic to parse the timezone.

cc: @pganssle

pganssle · 2017-12-09T14:45:45Z

@abalkin Unless I'm doing something wrong, it seems that the pure python implementation of isoformat() doesn't actually support subsecond precision.

import sys 
sys.modules['_datetime'] = None     # cause ImportError
from datetime import *

print(time(12, 30, 15, tzinfo=timezone(timedelta(microseconds=123456))).isoformat())
# 12:30:15+00:00:00

print(datetime(2017, 1, 1, 12, 30, 15,
      tzinfo=timezone(timedelta(microseconds=123456))).isoformat())
# Traceback (most recent call last):
#  File "<stdin>", line 2, in <module>
#  File ".../cpython/Lib/datetime.py", line 1832, in isoformat
#   assert not ss.microseconds
# AssertionError

I suppose I'll fix that as part of this PR.

pganssle · 2017-12-09T15:15:27Z

Latest changes fix both isoformat() and fromisoformat() in pure python and C implementations for subsecond offsets.

pganssle · 2017-12-10T02:23:40Z

Doc/library/datetime.rst

+
+  Return a :class:`datetime` corresponding to a *date_string* in one of the
+  ISO 8601 formats emitted by :meth:`datetime.isoformat`. Specifically, this function
+  supports strings in the format(s) ``YYYY-MM-DD[*[HH[:MM[:SS[.mmm[mmm]]]]][+HH:MM]]``,


Documentation needs updating to reflect second and microsecond precision.

abalkin · 2017-12-13T02:13:29Z

it seems that the pure python implementation of isoformat() doesn't actually support subsecond precision.

@pganssle - It looks like you are right. Please mention bpo-5288 in the commit message when you fix this. Please also find out why this was not caught by the test suit. We should be running all tests with and without C acceleration.

See bpo-5288

pganssle · 2017-12-13T02:21:01Z

@abalkin It's already fixed and tests added. I didn't see any tests actually testing subsecond support for timezones in .isoformat, which is why it wasn't caught by the tests.

I just pushed a rewritten history that mentions bpo-5288 in the commit fixing the pure python version.

abalkin · 2017-12-13T02:54:17Z

@pganssle - great job! This PR looks good to me now and I will merge it in a few days to give others a chance to review.

vadmium · 2017-12-17T23:42:24Z

Doc/library/datetime.rst

+
+  Return a :class:`time` corresponding to a *time_string* in one of the ISO 8601
+  formats emitted by :meth:`time.isoformat`. Specifically, this function supports
+  strings in the format(s) ``HH[:MM[:SS[.mmm[mmm]]]]][+HH:MM[:SS[.ffffff]]]``.


Too many square brackets.

vadmium · 2017-12-17T23:58:44Z

Doc/library/datetime.rst

+.. classmethod:: datetime.fromisoformat(date_string)
+
+  Return a :class:`datetime` corresponding to a *date_string* in one of the
+  ISO 8601 formats emitted by :meth:`datetime.isoformat`. Specifically, this function


I would drop “ISO 8601” and just say “one of the formats emitted by isoformat”. As far as I understand, ISO 8601 doesn’t have a seconds field in time zones, but it seems you want to support this.

If you intend to support dates without the time part, maybe write “emitted by datetime.isoformat and date.isoformat”. This may also need a test case; I didn’t notice anything relevant.

@vadmium The test cases from TestDate are actually inherited by TestDateTime, so it is indeed supported. I think it's fair to support them.

vadmium · 2017-12-18T00:04:56Z

Lib/datetime.py

+        try:
+            assert len(date_string) == 10
+            return cls(*_parse_isoformat_date(date_string))
+        except:


Write except Exception, to avoid catching KeyboardInterrupt or similar. Or even better, be explicit and list the exceptions you are expecting (AssertionError, ValueError, IndexError?).

@vadmium I think catching Exception is probably the right thing to do, I didn't think about KeyboardInterrupt. I'm mainly trying to get the C implementation and the Python implementation to always raise the same exceptions, and the C implementation only ever raises ValueError (I will fuzz it some time this week to verify this), hence the catch-and-re-raise.

vadmium · 2017-12-18T00:09:26Z

Lib/datetime.py

@@ -1193,19 +1320,7 @@ def __hash__(self):
    def _tzstr(self, sep=":"):


Good opportunity to remove the unsupported sep parameter

vadmium · 2017-12-18T00:13:43Z

Lib/datetime.py

@@ -1193,19 +1320,7 @@ def __hash__(self):
    def _tzstr(self, sep=":"):
        """Return formatted timezone offset (+xx:xx) or None."""


or the empty string

vadmium · 2017-12-18T00:43:59Z

Doc/library/datetime.rst

+  Return a :class:`datetime` corresponding to a *date_string* in one of the
+  ISO 8601 formats emitted by :meth:`datetime.isoformat`. Specifically, this function
+  supports strings in the format(s) ``YYYY-MM-DD[*HH[:MM[:SS[.mmm[mmm]]]]][+HH:MM[:SS[.ffffff]]]``,
+  where ``*`` can match any single character.


I think it would be less ambiguous putting the time zone inside the optional time part. Test case:

datetime(2017, 12, 18, 11, 0).isoformat(sep="+", timespec="minutes") -> "2017-12-18+11:00"
datetime.fromisoformat("2017-12-18+11:00") -> datetime(2017, 12, 18, 11, 0)

Hmmm.. As much as I dislike the idea of timezone being part of the time component, this is fine I suppose (and in fact that is how it is currently implemented).

That said, another design I considered is one where we take sep as a keyword argument to isoparse, which would relieve this ambiguity for all separators other than - and + if we wanted to eventually allow parsing of strings of the format YYYY-MM-DD+HH:MM. That's one decision we'd have to make in this version because changing it would not be backwards compatible.

vadmium · 2017-12-18T01:12:29Z

Doc/library/datetime.rst

+
+  Return a :class:`date` corresponding to a *date_string* in one of the ISO 8601
+  formats emitted by :meth:`date.isoformat`. Specifically, this function supports
+  strings in the format(s) ``YYYY-MM-DD``.


There is only one format emitted by date.isoformat and supported by your date.fromisoformat, as far as I know.

vadmium · 2017-12-18T01:17:09Z

Doc/library/datetime.rst

+
+Other constructor:
+
+.. classmethod:: time.fromisoformat(date_string)


time_string?

pganssle · 2017-12-18T02:30:10Z

@vadmium Thanks for all the comments. I've added a test for the ambiguous cases you identified and updated the documentation (plus dropped the unused sep parameter).

pganssle · 2017-12-18T15:20:39Z

@abalkin @vadmium Any thoughts on the question of whether to add a sep parameter to fromisoformat (from this now-hidden comment)?

The only reason to do so would be if in a future release we want to support ISO-8601 style strings that are just dates with offsets attached (e.g. 2017-01-01+12:00). I'm not sure, but I think ISO-8601 makes time zone offsets a property of time, so such dates-with-offsets are probably not actually valid ISO-8601 strings. Because 2017-01-01+12:00 could have been generated from datetime.isoformat(sep='+'), in its current form it would be impossible to get fromisoformat to interpret that +12:00 as anything except the time component. If we make the default behavior "strict", then in the future we would be able to support these "out of the box", specifying the separator as + or - would cause these style strings to be interpreted as times, and otherwise they would be offsets.

Having given this a bit of thought, I think it's probably a good idea to leave out sep, and if we want to support this use case in future releases, specifying a separator other than + or - would allow these things to be parsed as intended. Having the default value ignore the separator will make it easier to handle what is probably the most frequent use cases, which will be sep=' ' and sep='T' out of the box without any sort of branching to detect which one you're in, etc.

If we assume that some fraction of people will want to be strict and some people will want to be lenient, no matter which one we choose, the other behavior can easily be emulated. If we choose lenient by default, strict users can do the equivalent with:

def strict_fromisoformat(dtstr, sep='T'):
    if dtstr[10:11] != sep:
        raise ValueError('Invalid isoformat string: %s' % dstr)
    return datetime.fromisoformat(dtstr)

If we choose strict by default, the "lenient by default" option is:

def lenient_fromisoformat(dtstr):
    # Assuming sep requires a single character be passed, for dates it can be anything
    return datetime.fromisoformat(dtstr, sep=dtstr[10:11] or 'T')

Anyway, this is a kind of long comment just to say, "I think we should keep the status quo", but I thought I'd at least outline my thinking.

abalkin · 2017-12-19T04:25:41Z

Any thoughts on the question of whether to add a sep parameter to fromisoformat

-1 or adding a parameter, but I would not mind having fromisoformat() not checking the separator at all.

pganssle · 2017-12-19T12:47:37Z

@abalkin The current behavior is to allow any single character for the separator at all, if that's what you mean.

abalkin · 2017-12-19T22:55:00Z

The current behavior is to allow any single character for the separator at all, if that's what you mean.

Yes. That's what I want.

the-knights-who-say-ni added the CLA signed label Dec 4, 2017

bedevere-bot added the awaiting review label Dec 4, 2017

pganssle changed the title ~~Implement [date][time].fromisoformat (GH-15873)~~ [bpo-15873] Implement [date][time].fromisoformat Dec 4, 2017

pganssle force-pushed the from_isoformat branch from 2eb060d to 8f7f1b1 Compare December 4, 2017 17:44

pganssle force-pushed the from_isoformat branch from 8f7f1b1 to a957534 Compare December 4, 2017 17:50

pganssle changed the title ~~[bpo-15873] Implement [date][time].fromisoformat~~ bpo-15873: Implement [date][time].fromisoformat Dec 4, 2017

pganssle force-pushed the from_isoformat branch from a957534 to d7657a6 Compare December 4, 2017 18:08

abalkin requested changes Dec 4, 2017

View reviewed changes

bedevere-bot added awaiting changes and removed awaiting review labels Dec 4, 2017

vadmium reviewed Dec 4, 2017

View reviewed changes

pganssle commented Dec 5, 2017

View reviewed changes

pganssle force-pushed the from_isoformat branch 2 times, most recently from 39a65c3 to df3c032 Compare December 5, 2017 01:53

pganssle commented Dec 5, 2017

View reviewed changes

vadmium reviewed Dec 5, 2017

View reviewed changes

pganssle force-pushed the from_isoformat branch from df3c032 to 2a83701 Compare December 5, 2017 11:40

abalkin requested changes Dec 5, 2017

View reviewed changes

pganssle commented Dec 7, 2017

View reviewed changes

pganssle force-pushed the from_isoformat branch from 9e37ae8 to fb32d7f Compare December 7, 2017 17:35

pganssle commented Dec 10, 2017

View reviewed changes

pganssle added 5 commits December 10, 2017 11:08

Add documentation for [date][time].fromisoformat()

af9e6d0

Consolidate helper functions into parse_digits

cf802af

Refactor datetime.isoformat round trip tests

626d239

Refactor C code for PEP 7

7c771e7

Add support for seconds in fromisoformat offsets

8fbd752

pganssle force-pushed the from_isoformat branch from 43f7ff5 to 3da73a3 Compare December 10, 2017 11:09

abalkin approved these changes Dec 13, 2017

View reviewed changes

bedevere-bot added awaiting merge and removed awaiting changes labels Dec 13, 2017

abalkin self-assigned this Dec 13, 2017

pganssle added 2 commits December 12, 2017 21:20

Fix pure python implementation of isoformat() for sub-second zones

4d55e05

See bpo-5288

Add support for subsecond offsets to fromisoformat

5a233fb

pganssle force-pushed the from_isoformat branch from 3da73a3 to 5a233fb Compare December 13, 2017 02:20

vadmium reviewed Dec 18, 2017

View reviewed changes

pganssle added 3 commits December 17, 2017 21:09

Fix documentation and pure python error catching in fromisoformat

9fa91db

Drop unsupported sep parameter in _tzstr

ffdb2af

Add test for ambiguous isoformat strings

18a5fa8

abalkin merged commit 09dc2f5 into python:master Dec 21, 2017

bedevere-bot removed the awaiting merge label Dec 21, 2017

pganssle mentioned this pull request Jan 17, 2018

bpo-10381: Add timezone to datetime C API #5032

Merged

abalkin mentioned this pull request Mar 1, 2018

bpo-15873: add '.fromisoformat' for date, time and datetime #4841

Closed

pganssle deleted the from_isoformat branch October 25, 2018 14:30


		dt_rt = DateSubclass.fromisoformat(dt.isoformat())

		self.assertIsInstance(dt_rt, DateSubclass)

		@@ -1193,19 +1320,7 @@ def __hash__(self):
		def _tzstr(self, sep=":"):

		@@ -1193,19 +1320,7 @@ def __hash__(self):
		def _tzstr(self, sep=":"):
		"""Return formatted timezone offset (+xx:xx) or None."""


		Other constructor:

		.. classmethod:: time.fromisoformat(date_string)

bpo-15873: Implement [date][time].fromisoformat #4699

bpo-15873: Implement [date][time].fromisoformat #4699

Conversation

pganssle commented Dec 4, 2017 • edited Loading

pganssle commented Dec 4, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bedevere-bot commented Dec 4, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pganssle commented Dec 5, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pganssle Dec 5, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mariocj89 commented Dec 6, 2017

pganssle commented Dec 6, 2017

Choose a reason for hiding this comment

abalkin commented Dec 7, 2017

pganssle commented Dec 9, 2017 • edited Loading

pganssle commented Dec 9, 2017

Choose a reason for hiding this comment

abalkin commented Dec 13, 2017

pganssle commented Dec 13, 2017

abalkin commented Dec 13, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pganssle Dec 18, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pganssle commented Dec 18, 2017 • edited Loading

pganssle commented Dec 18, 2017

abalkin commented Dec 19, 2017

pganssle commented Dec 19, 2017

abalkin commented Dec 19, 2017

pganssle commented Dec 4, 2017 •

edited

Loading

pganssle Dec 5, 2017 •

edited

Loading

pganssle commented Dec 9, 2017 •

edited

Loading

pganssle Dec 18, 2017 •

edited

Loading

pganssle commented Dec 18, 2017 •

edited

Loading