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

[Guido van Rossum]

On Sat, Aug 22, 2015 at 3:35 PM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

>
>
> On Sat, Aug 22, 2015 at 6:11 PM, Guido van Rossum <guido at python.org>
> wrote:
>
>> On Sat, Aug 22, 2015 at 2:53 PM, Alexander Belopolsky <
>> alexander.belopolsky at gmail.com> wrote:
>>
>>> Some people on this list claimed that the following behavior is a bug:
>>>
>>> >>> (t + timedelta(100)).strftime('%F %T %Z%z')
>>> '2015-11-30 17:45:51 EDT-0400'
>>>
>>> because the correct result should be '2015-11-30 16:45:51 EST-0500'.
>>>
>>> My answer to that is that if you need that result, you can get it, but
>>> you have to ask for it explicitly:
>>>
>>> >>> (t + timedelta(100)).astimezone().strftime('%F %T %Z%z')
>>> '2015-11-30 16:45:51 EST-0500'
>>>
>>> I don't think we can do much here other than to educate Python users.
>>>
>>
>> It is disappointing that you still believe this, because the intention of
>> introducing DST-aware tzinfo objects was to be able to get the latter
>> answer. The trick that pytz uses to obtain timeline arithmetic causes it to
>> use only fixed-offset tzinfo objects. It's true that some platforms may not
>> give enough information about the local timezone to do better -- but others
>> do. There is no requirement that tzname is unique to determine all the
>> properties of a timezone.
>>
>
> There is nothing here to believe or not to believe.  If there is a bug in
> the datetime module -- we should fix it.  If not -- we should educate the
> users who think the current behavior is a bug.
>
> 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.
>

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.

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

PS. I've never used pytz or tried to read its docs. I am merely going by
what I think I read during this discussion. If I've got my facts wrong then
I apologize.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150822/6275c5c5/attachment.html>