On Sat, Aug 22, 2015 at 3:35 PM, Alexander Belopolsky < [email protected]> wrote:
> > > On Sat, Aug 22, 2015 at 6:11 PM, Guido van Rossum <[email protected]> > wrote: > >> On Sat, Aug 22, 2015 at 2:53 PM, Alexander Belopolsky < >> [email protected]> 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)
_______________________________________________ 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/
