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

Stuart Bishop stuart at stuartbishop.net
Mon Aug 24 16:24:27 CEST 2015


On 23 August 2015 at 09:05, Tim Peters <tim.peters at gmail.com> wrote:
>> 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").

My, that was a long time ago.

I think interoperability is the biggest issue. Timezones where a big
hassle to Australian's writing web applications, because most of the
world thought EST meant American Eastern Standard Time while we all
knew the correct answer was Australian Eastern Standard Time, or for
the rest of the year Australian Eastern Summer Time. So we used
timezone aware timestamps to avoid these silly assumptions (and cursed
zope.DateTime which hardcoded EST to the USA). And tried to keep all
our timestamps in UTC as best practice. But you still had to deal with
localized timestamps of course, and converting them to UTC and back to
perform arithmetic was a pain in the bum and something lazy devs often
didn't bother to do, and that is where the Python implementation fell
down. It needed to drop the is_dst flag for pickle size related
reasons IIRC, but without that flag you can't do datetime arithmetic
that crosses DST boundaries correctly. It had a limitation, and it was
documented, and we moved on because apart from this little wart it is
a nice module to use and fixing it would have made my ZODB2 database
bloat.

And then I realized that I could store that single bit of information
in the tzinfo instance, and went and implemented pytz because I was
young and foolish. And then Gustavo released dateutils, which avoided
the issue by avoiding the issue, and prompted me to get off my arse,
fix the remaining tests and release it.

Conversion was the larger issue, and to do that correctly the
arithmetic needed to be fixed. I never thought I was fixing the
arithmetic or implementing a particular style - I was just getting my
test suite to pass (which is generated from every transition stored in
the IANA nee Olson database).


-- 
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/


More information about the Datetime-SIG mailing list