<div dir="ltr">At the risk of being off-topic, I realize I really DO NOT currently understand datetime in its current incarnation. It's too bad PEP 431 proves so difficult to implement.<div><br></div><div>Even using `pytz` is there any way currently to get sensible answers to, e.g.:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div style="font-size:11.1999998092651px"><font face="monospace, monospace">from datetime import *</font></div></div><div><div style="font-size:11.1999998092651px"><font face="monospace, monospace">from pytz import timezone</font></div></div><div><div style="font-size:11.1999998092651px"><font face="monospace, monospace">pacific = timezone('US/Pacific')</font></div></div><div><div style="font-size:11.1999998092651px"><font face="monospace, monospace">pacific.localize(datetime(2015, 11, 1, 1, 30)) # Ambiguous time</font></div></div><div><div style="font-size:11.1999998092651px"><font face="monospace, monospace">pacific.localize(datetime(2015, 3, 8, 2, 30)) # Non-existent time</font></div></div></blockquote><div style="font-size:11.1999998092651px"><br></div><div style="font-size:11.1999998092651px">That is, what if I had *not* just looked up when the time change happens, and was innocently trying to define one of those datetimes above? Is there ANY existing way to have an error raised—or check in some other way—for the fact that one of the times occurs twice on my clock, and the other never occurs at all?</div><div><div style="font-size:11.1999998092651px"><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 25, 2015 at 8:31 PM, Lennart Regebro <span dir="ltr"><<a href="mailto:regebro@gmail.com" target="_blank">regebro@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Jul 26, 2015 at 2:56 AM, Tim Peters <<a href="mailto:tim.peters@gmail.com">tim.peters@gmail.com</a>> wrote:<br>
> However, the _body_ of the PEP said nothing whatsoever about altering<br>
> arithmetic. The body of the PEP sounds like it's mainly just<br>
> proposing to fold the pytz package into the core. Perhaps doing<br>
> _just_ that much would get this project unstuck? Hope springs eternal<br>
> :-)<br>
<br>
</span>The pytz package has an API and a usage that is different from the<br>
datetime() module. One of the things you need to do is that after each<br>
time you do arithmetic, you have to normalize the result. This is done<br>
because the original API design did not realize the difficulties and<br>
complexities of timezone handling and therefore left out things like<br>
ambiguous times.<br>
<br>
The PEP attemps to improved the datetime modules API so that it can<br>
handle the ambiguous times. It also says that the implementation will<br>
be based on pytz, because it was my assumption that this would be<br>
easy, since pytz already handles ambiguous times. During my attempt of<br>
implementing it I realized it wasn't easy at all, and it wasn't as<br>
easy as folding pytz into the core.<br>
<br>
Yes, the PEP gives that impression, because that was the assumption<br>
when I wrote the draft. Just folding pytz into the core without<br>
modifying the API defeats the whole purpose of the PEP, since<br>
installing pytz is a trivial task.<br>
<span class=""><br>
> Like what? I'm still looking for a concrete example of what "the<br>
> problem" is (or even "a" problem).<br>
<br>
</span>A problem is that you have a datetime, and add a timedelata to it, and<br>
it should then result in a datetime that is actually that timedelta<br>
later. And if you subtract the same timedelta from the result, it<br>
should return a datetime that is equal to the original datetime.<br>
<br>
This sounds ridiculously simple, and is ridiculously difficult to make<br>
happen in all cases that we want to support (Riyahd time zone and leap<br>
seconds not included). That IS the specific, concrete problem, and if<br>
you don't believe me, there is nothing I can do to convince you.<br>
Perhaps I am a complete moron and simply incompetent to do this, and<br>
in that case I'm sure you could implement this over a day, and then<br>
please do so, but for the love of the founders of computing I'm not<br>
going to spend more time repeating it on this mailing list, because<br>
then we would do better in having you implement this instead of<br>
reading emails. Me repeating this a waste of time for everyone<br>
involved, and I will now stop.<br>
<br>
> <discussing why Python's datetime is dfferent><br>
<br>
I was not involved in the discussion then, and even if I had been,<br>
that's still before I knew anything about the topic. I don't know what<br>
the arguments were, and I don't think it's constructive to try to<br>
figure out exactly why that decision was made. That is all to similar<br>
to assigning blame, which only makes people feel bad. Those who get<br>
blamed feel bad, and those who blame feel like dicks and onlookers get<br>
annoyed. Let us look forward instead.<br>
<br>
I am operating both without any need to defend that decision, as I was<br>
not involved in it, and I am operating with 20/20 hindsight as I am<br>
one of the few people having tried to implement a timezone<br>
implementation that supports ambiguous datetimes based on that<br>
decision. And then it is perfectly clear and obvious that the decision<br>
was a mistake and that we should rectify it.<br>
<br>
The only question for me is how and when.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Keeping medicines from the bloodstreams of the sick; food <br>from the bellies of the hungry; books from the hands of the <br>uneducated; technology from the underdeveloped; and putting <br>advocates of freedom in prisons. Intellectual property is<br>to the 21st century what the slave trade was to the 16th.<br></div>
</div>