[Lennart Regebro
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.
[Tim]
Could you please be explicit about what "the problem" is? Everyone here is guessing at what you think "the problem" is.
[Lennart]
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.
I believe everyone here is saying it "shouldn't be" exceedingly complicated, or even particularly hard, if you add the is_dst flags the PEP says it would add. But is the PEP complete? Under the "Postponement" section, it says: The implementation has turned out to be exceedingly complex, due to having to convert back and forth between the local time and UTC during arithmetic and adjusting the DST for each arithmetic step, with ambiguous times being particularly hard to get right. However, the _body_ of the PEP said nothing whatsoever about altering arithmetic. The body of the PEP sounds like it's mainly just proposing to fold the pytz package into the core. Perhaps doing _just_ that much would get this project unstuck? Hope springs eternal :-)
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.
Like what? I'm still looking for a concrete example of what "the problem" is (or even "a" problem).
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.
Somebody first needs to define what "the problem" is ;-)
There really is a reason every other date time implementation I know of uses UTC internally,
Yes, but the fundamental reason datetime does not is that Guido consciously and deliberately decided that "naive datetime" would be most useful most often for most users. That's why "naive" objects are the default. And even for "aware" objects, arithmetic staying within a single time zone was deliberately specified to be "naive" too. My guess is that all other datetime implementations you know of have no concept of "naive" datetimes. let alone make naive datetimes primary. Small wonder, if so, that they're all different in this way. That's a design decision not everyone likes, and certainly isn't suitable for all purposes, but the debate over that ended a dozen years ago when the decision was made. If your vision of PEP 431 _changes_ that design decision (which it sure _sounds_ like it wants to based on what you're typing here, but which PEP 431 itself does not appear to say - impossible to tell which from here without any specific example(s)), that may account for all sorts of complications that aren't apparent to me.
and there really is a reason why everyone always recommends storing date times in UTC with the time zone or offset separately.
Well, that's the second thing they recommend - and they can already do that. The first thing to recommend is to use naive objects in any application where that's possible, so that you don't have to bother with _any_ time zone esoterica, surprises, complications or overheads. After all, it's 7:54 PM as I type this, and that's perfectly clear to me ;-)