On Sat, Aug 22, 2015 at 7:02 PM, Guido van Rossum <[email protected]> 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.
_______________________________________________
Datetime-SIG mailing list
[email protected]
https://mail.python.org/mailman/listinfo/datetime-sig
The PSF Code of Conduct applies to this mailing list:
https://www.python.org/psf/codeofconduct/
