Re: [Datetime-SIG] Calendar vs timespan calculations...
On 08/01/2015 12:09 PM, Alexander Belopolsky wrote:
On Sat, Aug 1, 2015 at 2:34 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
My goal here is to minimize the impact on the programs that are already written and deployed.
Why is this even a problem? Already written programs will not be using the new strict tzinfo.
They will if their tzinfo provider switches to tzstrict.
It is not our problem if a third-party library makes backwards incompatible changes. We will still be supporting all three types in the stlib: naive, aware, and strict. If this new 'strict' support still has buggy behaviour around time shifts, why are we bothering? -- ~Ethan~
On Sat, Aug 1, 2015 at 3:40 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
If this new 'strict' support still has buggy behaviour around time shifts, why are we bothering?
Because the new 'strict' way of dealing with timezones and datetime arithmetics will become our "gold standard" and we will not tolerate buggy behavior even in the corner cases? Speaking seriously, however, the part that I really want to salvage is Tim's clever algorithm that implements fromutc() once the user provided utcoffset() and dst() methods. This algorithm relies on a technically illegal operation: calling utcoffset() and dst() on a datetime instance representing time in UTC. If we allow utcoffset() or dst() raise an error on some values of datetime - this algorithm won't work. [1]: https://hg.python.org/cpython/file/f6a3310d3cc9/Lib/datetime.py#l957
participants (2)
-
Alexander Belopolsky -
Ethan Furman