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

Chris Barker chris.barker at noaa.gov
Thu Oct 26 12:45:31 EDT 2017

On Wed, Oct 25, 2017 at 7:37 PM, Wes Turner <wes.turner at 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/ISO8601#Timezonedesignators

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 at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171026/dd942b4f/attachment.html>

More information about the Python-Dev mailing list