[Datetime-SIG] Is EDT a timezone? Was: PEP-0500

Tim Peters tim.peters at gmail.com
Sun Aug 23 04:05:16 CEST 2015

> But PEP 495 doesn't add timeline arithmetic (it merely makes it easier to
> convert between timestamps and datetimes and back, except for the rounding
> issue).

That's kinda like saying Python doesn't do anything (it merely makes
it easier to write programs ;-) ).  PEP 495 supplies something needed
to go on to implement timeline arithmetic, and to reliably _convert_
between timezones (which you may think of as converting to timestamps,
doing arithmetic, then converting back - but astimezone() is "a
primitive" to datetime users).

> I wonder why Stuart needed timeline arithmetic? Merely being able to access
> the Olson database doesn't sound enough of a reason for such heroism.

dateutil also wraps the Olson database (among several other sources of
timezone info), but made no effort to change Python's default
haphazard treatment of folds and gaps.

I'd be interested to hear Stuart's thoughts on this.  Back when I was
searching the web for clues, I mostly saw people (blogs, message
threads) speculating about _conversion_ (not mostly arithmetic)
surprises.  Note that once 495-compliant tzinfos exist, zone
conversions using them will work correctly in all cases by magic (no
change to arithmetic is required - classic arithmetic is what's needed
for those and we already have it - conversions today only trip over
the current inability to disambiguate folds - as the docs say, for the
default .fromutc() to mimic the local clock in all cases, .dst() must
consider an ambiguous time to be "in standard time" - which is wrong
"half the time").

Here's a "typical enough" bloggish compilation of possible complaints.


Also typical is its:

It may seem unlikely that your application will ever hit the problem
I’ve demonstrated here, but in many cases I bet you can imagine how it
is possible, and that’s enough for me. I prefer to err on the side of

and its:

I will (hopefully) never need to care about them. I avoid them by
simply using UTC whenever possible.

Your predilection for thinking of datetimes as timestamps is, I
believe, more natural in the datetime context as a predilection for
sticking to UTC (which is really just a richer - and better-behaved
(due to larger range and lack of floating-point surprises) - way of
spelling a POSIX timestamp extended to microsecond precision).

More information about the Datetime-SIG mailing list