Can you update the PEP with a small note about this and update the status to Postponed? Switching to UTC is a big change indeed.

Or could you leave this issue unsolved and still make progress with the tz database?

In any case, new discussion should then go back to python-ideas.

On Thu, Jul 23, 2015 at 6:22 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Thu, Jul 23, 2015 at 5:07 PM, Guido van Rossum <guido@python.org> wrote:
> Sorry for reviving this thread, but I was cornered at EuroPython with a
> question about the status of this PEP. It seems the proposal ran out of
> steam and has now missed the Python 3.5 train. What happened? Is the problem
> unsolvable? Or could we get this into 3.6???

It turns out it's very complex to solve this when internally storing
the time as the local time. Basically you have to normalize the time
(ie check if daylight savings have changed) when doing arithmetic, but
normalize is doing arithmetic, and you get infinite recursion. I've
tried various ways to solve this but ran out of steam/brainpower.

I think we should look into storing as UTC internally instead. It's a
big change (and also needs handling pickles in a backwards compatible
way) but I think that's the way forward.

//Lennart



--
--Guido van Rossum (python.org/~guido)