[Datetime-SIG] Is EDT a timezone? Was: PEP-0500
Guido van Rossum
guido at python.org
Sun Aug 23 02:15:37 CEST 2015
On Sat, Aug 22, 2015 at 4:43 PM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:
> On Sat, Aug 22, 2015 at 7:02 PM, Guido van Rossum <guido at python.org>
> [Alexander Belopolsky]
>> The feature lack of which you may find disappointing is that we don't
>>> have the means in the stdlib to get the following:
>>> >>> t = datetime.now(LocalZone)
>>> >>> t.strftime('%F %T %Z%z')
>>> '2015-08-22 17:45:51 EDT-0400'
>>> >>> (t + timedelta(100)).strftime('%F %T %Z%z')
>>> '2015-11-30 16:45:51 EST-0500'
>>> I agree. It would be nice to have something like this (and agree
>>> whether it should return 17:45 or 16:45). However, this has nothing to
>>> do with having or not having the bug in the library that we ship today.
>>> At some point we draw the line saying that the standard datetime module
>>> will only implement fixed offset timezones. These timezones were
>>> implemented and for the most part correctly. At least in the examples that
>>> I provided the code works the way I expect it to work.
>> [Guido van Rossum]
>> Ah. I think I finally understand why we're failing to communicate. Your
>> claim is merely that the stdlib doesn't have the means to construct a
>> tzinfo with the desirable behavior from the timezone information available
>> in the time module. We have the tzname tuple and the offset for the current
>> time, but nothing about the DST transition algorithm, so the best we can do
>> is create a fixed-offset tzinfo for the current offset. I will give you
> It's not that we don't have the means. After all, the mktime-based LocalZone
> implementation have been presented in the library manual for ages. I think
> it was the same ambiguity about folds and gaps and the traditional vs.
> timeline arithmetic that prevented it from getting into the datetime module.
> The fixed offset timezones solved a very practical problem: you get an
> email for someone in Australia with a timestamp in UTC+10:00 timezone
> (which includes +1000 in it) and you want to compare it to datetime.now().
> This problem is solved in Python 3.3+. As a bonus, you also have means of
> doing the timeline arithmetic, but not as easily as one might wish.
I would have solved this problem (and any other problem that requires
timeline arithmetic) by converting to a timestamp and comparing to
>> What I am objecting to is that when you ask pytz to construct a datetime
>> from a DST-aware timezone, it produces a datetime whose tzinfo has a fixed
>> offset. Such a datetime then exhibits the same behavior as shown in your
>> example for LocalZone, even though pytz has the DST rules for the original
>> timezone -- and this is what I called "trading one bug for another" (since
>> pytz does this in order to obtain timeline arithmetic).
> The author of pytz had no means of storing the extra bit necessary to do
> timeline arithmetic in local time notation in the datetime object. So for
> him, what was a more or less an arbitrary choice for us was a necessity.
> As Tim characterized it, Stuart made a heroic effort to overcome that
> limitation. Hopefully with PEP 495 we will resolve this issue once and for
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
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.
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Datetime-SIG