On Sun, Jul 26, 2015 at 2:56 AM, Tim Peters firstname.lastname@example.org wrote:
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 :-)
The pytz package has an API and a usage that is different from the datetime() module. One of the things you need to do is that after each time you do arithmetic, you have to normalize the result. This is done because the original API design did not realize the difficulties and complexities of timezone handling and therefore left out things like ambiguous times.
The PEP attemps to improved the datetime modules API so that it can handle the ambiguous times. It also says that the implementation will be based on pytz, because it was my assumption that this would be easy, since pytz already handles ambiguous times. During my attempt of implementing it I realized it wasn't easy at all, and it wasn't as easy as folding pytz into the core.
Yes, the PEP gives that impression, because that was the assumption when I wrote the draft. Just folding pytz into the core without modifying the API defeats the whole purpose of the PEP, since installing pytz is a trivial task.
Like what? I'm still looking for a concrete example of what "the problem" is (or even "a" problem).
A problem is that you have a datetime, and add a timedelata to it, and it should then result in a datetime that is actually that timedelta later. And if you subtract the same timedelta from the result, it should return a datetime that is equal to the original datetime.
This sounds ridiculously simple, and is ridiculously difficult to make happen in all cases that we want to support (Riyahd time zone and leap seconds not included). That IS the specific, concrete problem, and if you don't believe me, there is nothing I can do to convince you. Perhaps I am a complete moron and simply incompetent to do this, and in that case I'm sure you could implement this over a day, and then please do so, but for the love of the founders of computing I'm not going to spend more time repeating it on this mailing list, because then we would do better in having you implement this instead of reading emails. Me repeating this a waste of time for everyone involved, and I will now stop.
<discussing why Python's datetime is dfferent>
I was not involved in the discussion then, and even if I had been, that's still before I knew anything about the topic. I don't know what the arguments were, and I don't think it's constructive to try to figure out exactly why that decision was made. That is all to similar to assigning blame, which only makes people feel bad. Those who get blamed feel bad, and those who blame feel like dicks and onlookers get annoyed. Let us look forward instead.
I am operating both without any need to defend that decision, as I was not involved in it, and I am operating with 20/20 hindsight as I am one of the few people having tried to implement a timezone implementation that supports ambiguous datetimes based on that decision. And then it is perfectly clear and obvious that the decision was a mistake and that we should rectify it.
The only question for me is how and when.