Mailman 3 August 2015 - Datetime-SIG

Re: [Datetime-SIG] Post-PEP 495 ideas Was: PEP-431/495
by Alexander Belopolsky 24 Aug '15

24 Aug '15

On Mon, Aug 24, 2015 at 5:58 PM, Ethan Furman <ethan(a)stoneleaf.us> wrote: > If we do go the route of not raising exceptions we should just add your > function to the datetime module and save people from mis-copying it. We will have plenty of time discussing this and other ideas after PEP 495 is accepted and implemented.

1 0

Re: [Datetime-SIG] pytz vs. PEP 495 Was: PEP-431/495
by Ethan Furman 24 Aug '15

24 Aug '15

On 08/24/2015 02:45 PM, Alexander Belopolsky wrote: > On Mon, Aug 24, 2015 at 5:32 PM, Ethan Furman wrote: > >> It is my contention that library code (such as datetime) should raise exceptions >> when something exceptional happens, and the program code can then handle it >> appropriately for that program: > > ... > > > # server program > try: > get_a_datetime_from_somewhere(ltdf=None) > except AmbiguousTimeError, NonExistentTimeError: > log(weird_time_error) > use_default() > > > I've been criticized on this list for using python-resembling pseudo-code, so I will > assume that what you show is an actual Python code. In this case, > `get_a_datetime_from_somewhere` and `use_default` lines have no visible effect on the > program and I have no guess for what they are supposed to do internally. You're right, I was sloppy. How's this: try: some_date = get_a_datetime_from_somewhere(ltdf=None) except AmbiguousTimeError, NonExistentTimeError as e: log(weird_time_error, e) some_date = use_default(e.datetime) and the datetime attribute of e would be the attempted datetime with the flag set to None (so it is either still ambiguous, or still doesn't exist), and then use_default() would do something with it. > I do show in the PEP how a function that raises an error on ambiguous/missing > time can be written. Writing functions to work around short-comings is not how I like to spend my time (see my contention above about library code). If we do go the route of not raising exceptions we should just add your function to the datetime module and save people from mis-copying it. -- ~Ethan~

2 1

Re: [Datetime-SIG] Conversion vs arithmetic (was Re: Is EDT a timezone? Was: PEP-0500)
by ISAAC J SCHWABACHER 24 Aug '15

24 Aug '15

[ijs] > > I guess I'll have to try to implement it and find out > > where the headaches are myself. [Tim Peters] > Have fun ;-) Always! :) > > It's also worth noting that backward compatibility cuts both > > ways: because Stuart Bishop has chosen to implement > > timeline arithmetic, any stdlib inclusion of pytz will have to > > support timeline arithmetic in some form in order to > > maintain backward compatibility with the package itself. > > We _could_ include pytz exactly the way it is today, without changing > anything (else) in Python or pytz. There are lots of ways to deal > with this. We could also say, more like dateutil did, that Python > finds the Olson database useful but wants _nothing_ to do with > timeline arithmetic, not ever. Etc. > > In any case, there is no active PEP at the moment proposing to add any > new timezone implementations to Python. One step at a time. PEP 431 did. But I agree, PEP 495 is a small and straightforward step in the right direction. Though it's not looking like the bikeshed is going to get painted my color. :) > > I see how PEP 495 makes it possible to convert datetimes correctly > > in all cases, > > Whew! You may well be only the second person to grasp this - thanks :-) Wait... was this ever in contention? > > but I don't see how it makes it possible to implement > > time zones that will be pytz-compatible without continuing to require > > the localize/normalize dance. > > Indeed it doesn't - nor does it preclude it. PEP 495 says nothing > whatsoever about timeline arithmetic, or about any other feature of > any external timezone library except to the extent it adds new > requirements on their Python-specifed tzinfo methods (chiefly > .utcoffset() and .fromutc()). > > If pytz plays along with 495, then there's a new baseline to start > from. For example, the current (I think) ptyz docs say: > > """ > Converting between timezones also needs special attention. We also need > to use the ``normalize()`` method to ensure the conversion is correct. > """ > > That dance "should" no longer be necessary. But I don't know - > perhaps pytz will continue to need it anyway. That's up to Stuart, > not to me. I assume pytz is committed for backward compatibility to timeline arithmetic for datetime subtraction, which means it can't afford to change its "one tz instance per offset" design as long as datetime arithmetic ignores the time zone when it's identical. There's no hook for pytz to hang its behavior on, and PEP 495 doesn't give it one. On the upside, it does look like there's a way to foil the dreaded self check in datetime_astimezone and make dt.astimezone(tz) work as intended. ijs

1 0

Re: [Datetime-SIG] pytz vs. PEP 495 Was: PEP-431/495
by Ethan Furman 24 Aug '15

24 Aug '15

On 08/24/2015 02:28 PM, ISAAC J SCHWABACHER wrote: > [ijs] >>>> I *really* hope the answer to this one is, "don't do that". > > [Alexander Belopolsky] >>> That's not an option because people already *do* [1] that and they won't stop. >>> Neither they will stop using datetime.combine() [2] or datetime.replace() [3] >>> or tolerate if those methods start raising exceptions. > > [Ethan Furman] >> If the default is True (or False), then this won't be a problem. It will only >> be None when explicitly asked for. >> >> `time` can just store the flag, and when it is combined with a date the flag >> should be checked and if None and the resulting datetime doesn't exist or is >> ambiguous an exception can be raised. > > A time with a non-constant-offset tzinfo is always ambiguous, and can have an > arbitrary number of possible offsets. There are several time zones with at least > three possible offsets for a given time in the last 10 years. How on earth do > you define the meaning of a time with a non-constant tzinfo attached? Or does it > only mean something when it's recombined with a date? I hope the only way I would use a plain time is for today (whichever day 'today' happens to be), in which case having a tzinfo is still helpful for knowing what time it is somewhere else. Which is still a buggy proposition on days involving time switches. -- ~Ethan~

2 1

Re: [Datetime-SIG] pytz vs. PEP 495 Was: PEP-431/495
by Ethan Furman 24 Aug '15

24 Aug '15

On 08/24/2015 02:10 PM, Alexander Belopolsky wrote: > I addressed three reasons why people want to have the third value for the fold > index in the recent version of the PEP. Let me just note that the three reasons > are mutually exclusive: for example, the first and last call for different defaults. > I suggest that the proponents of the fold=None/fold=-1 option first agree on one > specific behavior that they want and then we consider the virtues of such behavior > (if any). From the PEP: > Moreover, raising an error in the problem cases is only one of many possible > solutions. An interactive program can ask the user for additional input, while > a server process may log a warning and take an appropriate default action. We > cannot possibly provide functions for all possible user requirements, but this > PEP provides the means to implement any desired behavior in a few lines of code. It is my contention that library code (such as datetime) should raise exceptions when something exceptional happens, and the program code can then handle it appropriately for that program: # interactive program try: get_a_datetime_from_user(ltdf=None) except AmbiguousTimeError, NonExistentTimeError: get_clarification_from_user() # server program try: get_a_datetime_from_somewhere(ltdf=None) except AmbiguousTimeError, NonExistentTimeError: log(weird_time_error) use_default() -- ~Ethan~

2 1

Re: [Datetime-SIG] pytz vs. PEP 495 Was: PEP-431/495
by Ethan Furman 24 Aug '15

24 Aug '15

On 08/24/2015 01:44 PM, Alexander Belopolsky wrote: > On Mon, Aug 24, 2015 at 4:28 PM, ISAAC J SCHWABACHER wrote: > >> [ijs] >> I *really* hope the answer to this one is, "don't do that". > > That's not an option because people already *do* [1] that and they won't stop. > Neither they will stop using datetime.combine() [2] or datetime.replace() [3] > or tolerate if those methods start raising exceptions. If the default is True (or False), then this won't be a problem. It will only be None when explicitly asked for. `time` can just store the flag, and when it is combined with a date the flag should be checked and if None and the resulting datetime doesn't exist or is ambiguous an exception can be raised. -- ~Ethan~

3 2

Re: [Datetime-SIG] pytz vs. PEP 495 Was: PEP-431/495
by Alexander Belopolsky 24 Aug '15

24 Aug '15

On Mon, Aug 24, 2015 at 4:28 PM, ISAAC J SCHWABACHER <ischwabacher(a)wisc.edu> wrote: > [ijs] > I *really* hope the answer to this one is, "don't do that". > That's not an option because people already *do* [1] that and they won't stop. Neither they will stop using datetime.combine() [2] or datetime.replace() [3] or tolerate if those methods start raising exceptions. I am giving examples from datetime.py which in theory we can change, but what we use in datetime.py is likely to be used in user code as well. [1]: https://hg.python.org/cpython/file/v3.5.0rc1/Lib/datetime.py#l1476 [2]: https://hg.python.org/cpython/file/v3.5.0rc1/Lib/datetime.py#l1734 [3]: https://hg.python.org/cpython/file/v3.5.0rc1/Lib/datetime.py#l1540

1 0

Re: [Datetime-SIG] pytz vs. PEP 495 Was: PEP-431/495
by ISAAC J SCHWABACHER 24 Aug '15

24 Aug '15

[Alexander Belopolsky] > >>> dt = time(2, first=None, tzinfo=Eastern2) [ijs] I *really* hope the answer to this one is, "don't do that". ijs

1 0

Re: [Datetime-SIG] pytz vs. PEP 495 Was: PEP-431/495
by Alexander Belopolsky 24 Aug '15

24 Aug '15

On Mon, Aug 24, 2015 at 4:23 PM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > > On Mon, Aug 24, 2015 at 3:54 PM, Ethan Furman <ethan(a)stoneleaf.us> wrote: > >> Which of the steps you want to raise an exception: >>> >>> >>> dt = datetime(2004, 4, 4, 2, first=None, tzinfo=Eastern2) >>> >> >> This one. > > > and what about this one? > > >>> dt = time(2004, 4, 4, 2, first=None, tzinfo=Eastern2) > Sorry, did not delete enough: >>> dt = time(2, first=None, tzinfo=Eastern2)

1 0

Re: [Datetime-SIG] pytz vs. PEP 495 Was: PEP-431/495
by Ethan Furman 24 Aug '15

24 Aug '15

On 08/24/2015 12:14 PM, Alexander Belopolsky wrote: > On Mon, Aug 24, 2015 at 3:05 PM, Ethan Furman wrote: >> I would be much happier about this if: >> >> >>> datetime(2004, 4, 4, 2, first=None, tzinfo=Eastern2).astimezone().isoformat() >> Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File ".../pytz/tzinfo.py", line 327, in localize > raise NonExistentTimeError(dt) > NonExistentTimeError: 2004-04-04 02:00:00 > > Giving the programmer an easier option to use if they want an exception. > > > Which of the steps you want to raise an exception: > > >>> dt = datetime(2004, 4, 4, 2, first=None, tzinfo=Eastern2) This one. > and why? Because Python shouldn't be guessing. 'datetime' doesn't know how the programmer got those numbers, and so can't know whether subtraction was used and 1am is the right answer, or addition was used and 3am is the right answer. > The stack trace that you presented comes for "localize", but no such method > is proposed in PEP 495. Sorry, I copied the stack trace with only slight modification -- the import part is the NonExistantTimeError (or AmbiguousTimeError for the opposite scenario). -- ~Ethan~

2 1