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

Alexander Belopolsky alexander.belopolsky at gmail.com
Sun Aug 23 00:35:10 CEST 2015


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


More information about the Datetime-SIG mailing list