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 firstname.lastname@example.org wrote:
On Thu, Jul 23, 2015 at 5:07 PM, Guido van Rossum email@example.com 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
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.