On Thursday, October 26, 2017, Chris Barker firstname.lastname@example.org wrote:
ISO 8601 support offsets, but not time zones -- presumably the __str__
supports the full datetime tzinfo somehow. Which may be why .isoformat() exists.
ISO8601 does support timezones. https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
No, it doesn't -- it may call them "timezones", but it only supports offsets -- that is, and offset of -6 could be US Eastern Standard Time or US Central Daylight TIme (or I got that backwards :-) )
The point is that an offset is really easy, and timezones (with Daylight savings and all that) are a frickin' nightmare, but ARE supported by datetime
Note that the vocabulary is not precise here, as I see this in the Pyton docs:
A class that implements the tzinfo https://docs.python.org/3/library/datetime.html#datetime.tzinfo abstract base class as a fixed offset from the UTC. So THAT is supported by iso8601, and, indeed maps naturally to it.
Got it, thanks.
Which means we can round trip isp8601 datetimes nicely, but can't round trip a datetime with a "full featured" tzinfo attached.
Because an iso8601 string only persists the offset.
I don't think this really has any impact on the proposal, though: it's clear what to do when parsing a iso Datetime.
I might be wrong, but I think many of the third party libraries listed
here default to either UTC or timezone-naieve timezones: https://github.com/vinta/awesome-python/blob/master/README. md#date-and-time
This is a key point that I hope is obvious:
If an ISO string has NO offset or timezone indicator, then a naive datetime should be created.
(I say, I "hope" it's obvious, because the numpy datetime64 implementation initially (and for years) would apply the machine local timezone to a bare iso string -- which was a f-ing nightmare!)
astropy.time.Time supports numpy.
Ctrl-F for 'tzinfo=' in the docs really doesn't explain how to just do it with my local time.
Here's an example with a *custom* GMT1 tzinfo subclass: https://docs.python.org/3/library/datetime.html#datetime.time.tzname
Here it is:
class GMT1(tzinfo): def utcoffset(self, dt): return timedelta(hours=1) def dst(self, dt): return timedelta(0) def tzname(self,dt): return "Europe/Prague"
I hope Prague doesn't do DST, or that would be just wrong ...
Pendulum seems to have a faster timezone lookup than pytz:
Both pendulum and pytz are in conda-forge (the new basis for the anaconda distribution).
What would you call the str argument? Does it accept strptime args or only
I think Fred answered this, but iso 8601 only. we already have strptime if you need to parse anything else.
Would all of that string parsing logic be a performance regression from
the current constructor? Does it accept None or empty string?
I suppose you need to do a little type checking first, so a tiny one.
Though maybe just catching an Exception, so really tiny.
The current constructor only takes numbers, so yes the string parsing version would be slower, but only if you use it...
Deserializing dates from JSON (without #JSONLD and xsd:dateTime (ISO8601))
types is nasty, regardless (try/except, *custom* schema awareness). And pickle is dangerous.
AFAIU, we should not ever eval(repr(dt: datetime)).
why not? isn't that what __repr__ is supposed to do?
repr(dict) now returns ellipses ... for cyclical dicts; so I'm assuming that repr only MAY be eval'able.
Or do you mean not that it shouldn't work, but that we shouldn't do it?
That We shouldn't ever eval untrusted data / code. (That's why we need package hashes, signatures, and TUF).
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE https://maps.google.com/?q=7600+Sand+Point+Way+NE&entry=gmail&source=g (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception