[Datetime-SIG] Is EDT a timezone? Was: PEP-0500
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:
> 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Datetime-SIG