On Sat, Jul 25, 2015 at 7:12 AM, Tim Peters email@example.com wrote:
[Lennart Regebro firstname.lastname@example.org]
And I would want to remind everyone again that this is not a question of the problem being impossible. It's just really complex to get right in all cases, and that always having the UTC timestamp around gets rid of most of that complexity.
Could you please be explicit about what "the problem" is? Everyone here is guessing at what you think "the problem" is.
The problem is that it is exceedingly complicated to get all the calculations back and forth between local time and UTC to be correct at all times and for all cases. It really doesn't get more specific than that. I don't remember which exact problem it was that made me decide that this was not the correct solution and that we should use UTC internally, but I don't think that matters, because I'm also sure that it was not the last case, as I was far from near the end in adding testcases.
Once again I'm sure it's not impossible to somehow come up with an implementation and an API that can do this based on local time, but once again I am of the opinion that it is the wrong thing to do. We should switch to using UTC internally, because that will make everything so much simpler.
I am in no way against other people implementing this PEP, but I think you will end up with very complex code that will be hard to maintain.
There really is a reason every other date time implementation I know of uses UTC internally, and there really is a reason why everyone always recommends storing date times in UTC with the time zone or offset separately.