[Datetime-SIG] Calendar vs timespan calculations...
alexander.belopolsky at gmail.com
Sat Aug 1 20:18:11 CEST 2015
On Sat, Aug 1, 2015 at 1:52 PM, Ethan Furman <ethan at 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.
More information about the Datetime-SIG