On Sat, Aug 1, 2015 at 1:52 PM, Ethan Furman <ethan@stoneleaf.us> wrote:

As a case in point: Today I have veterinary appointment for my cat to check his medication levels; the appointment is at 14:30, and needs to be in the window of 4 to 6 hours of him taking his meds. Counting backwards from 14:30 gives me a window of 8:30 to 10:30 to administer his meds.

I'm happy to concede that counting backwards to get the start time is less frequent, and the times this hits/crosses a time shift are even less frequent, but that is all the more reason to refuse the temptation to guess.

My goal here is to minimize the impact on the programs that are already written and deployed. It is better to get a wrong time for one appointment than to loose all appointments due to a program crash. If your vet uses a naively written program, she probably already has a work-around for DST transitions. I want to make sure her workaround does not break with the future python releases. When you write a new program, you can easily write your own function that will do whatever you want when it detects an ambiguous time: from raising an exception to calling an airstrike on whatever agency is responsible for the DST transition. We may even provide convenience APIs in the tzstrict class to do something like the first option. What we cannot do is to make dt.utcoffset() or dt.dst() raise an exception in the case where they did not in the past releases of Python and popular timezone libraries.