On Tue, Aug 18, 2015 at 3:31 PM, Carl Meyer <[email protected]> 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. 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. 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.
_______________________________________________ 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/
