[Datetime-SIG] PEP 495 (Local Time Disambiguation) is ready for pronouncement

[Carl Meyer]

On 08/18/2015 02:09 PM, Alexander Belopolsky wrote:
> 
> On Tue, Aug 18, 2015 at 3:31 PM, Carl Meyer <carl at oddbird.net
> <mailto:carl at oddbird.net>> wrote:
> 
>     That project did a _ton_ of "construct naive
>     datetime by combining date and time, then convert that naive datetime to
>     a local timezone, raising an error if the resulting local time is
>     missing or ambiguous." That was trivial with the pytz API: if you
>     specify `tz.localize(naive_dt, is_dst=None)` you'll get an exception on
>     an ambiguous or missing result. It sounds less fun with PEP 495 (would
>     just require a wrapper function to do the conversions, so not too bad --
>     just feels wrong to do all the conversions twice, when internally
>     datetime should be able to know enough to just raise the exception I
>     want right away).
> 
> 
> PEP 495 is designed to avoid the exceptions for a reason.  When I enter
> a conference time in my scheduler, all I care is that an event is
> created, people are invited and I am reminded 15 minutes before it
> starts.  In most cases, I don't care which of the two ambiguous times is
> picked or even which of the two times around the missing time as log as
> the scheduler knows how to avoid conflicts and how to display the time
> to all participants in an unambiguous way.

"Most of the time I want..." or "the naive user wants..." arguments like
this are useful for picking a default behavior, and I agree with you
that "guess one way or the other" is a better _default_ behavior than
"raise an exception."

But in my case, I knew precisely what UX I wanted to provide in case of
ambiguous/missing times (and in the case of missing times, it did not
involve guessing in either direction), and I wanted the underlying
library to just clearly tell me about missing/ambiguous times so I could
handle them in my preferred way. I wish PEP 495 provided a simpler
(opt-in) way to do this.

  If I schedule an
> international conference call, I certainly don't want to see: your
> conference time is ambiguous in Uruguay, please pick another time.

Of course -- I wouldn't ever choose the "raise an exception if
ambiguous" option on the conversion from UTC to another timezone, I
would just want the flag set correctly on the resulting datetime. The
primary place where the option to raise an exception is useful (at least
in my case) is in converting from naive to local time, where the
resulting local time is nonexistent.

  Note
> that the goal was to make naively written software "just work" and
> produce consistent and defensible results.  Not providing any means to
> schedule in the second part of the fold is defensible: enjoy free time. 
> Scheduling a call for 2:30AM when user enters 1:30AM that does not exist
> is also defensible.  (1 hour and 30 minutes after the midnight on a
> spring-forward day is 2:30AM.)  A stack trace in the server log due to
> an uncaught exception is not a defensible result. 

Sure. All of these are arguments are about the default behavior. They
are not arguments against providing some opt-in mechanism to efficiently
discover when a conversion from naive time results in a nonexistent
localized time.

Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150818/f6273dda/attachment-0001.sig>