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

Alexander Belopolsky alexander.belopolsky at gmail.com
Sun Aug 23 01:43:54 CEST 2015


On Sat, Aug 22, 2015 at 7:02 PM, Guido van Rossum <guido at python.org> wrote:
[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
> that.
>

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.


> 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
all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150822/9f2f0271/attachment.html>


More information about the Datetime-SIG mailing list