On Sat, Aug 22, 2015 at 4:43 PM, Alexander Belopolsky < [email protected]> wrote:
> > 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. > I would have solved this problem (and any other problem that requires timeline arithmetic) by converting to a timestamp and comparing to time.time(). > > >> 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. > But PEP 495 doesn't add timeline arithmetic (it merely makes it easier to convert between timestamps and datetimes and back, except for the rounding issue). I wonder why Stuart needed timeline arithmetic? Merely being able to access the Olson database doesn't sound enough of a reason for such heroism. -- --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/
