[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>
> 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.
>

I would have solved this problem (and any other problem that requires
timeline arithmetic) by converting to a timestamp and comparing to
time.time().


>
>
>> 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.
>

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).

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...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150822/c3e14e3c/attachment-0001.html>


More information about the Datetime-SIG mailing list