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 <rege...@gmail.com> wrote: > On Thu, Jul 23, 2015 at 5:07 PM, Guido van Rossum <gu...@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
