[Python-Dev] Status on PEP-431 Timezones
mertz at gnosis.cx
Sun Jul 26 06:24:56 CEST 2015
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.
Even using `pytz` is there any way currently to get sensible answers to,
from datetime import *
from pytz import timezone
pacific = timezone('US/Pacific')
pacific.localize(datetime(2015, 11, 1, 1, 30)) # Ambiguous time
pacific.localize(datetime(2015, 3, 8, 2, 30)) # Non-existent time
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?
On Sat, Jul 25, 2015 at 8:31 PM, Lennart Regebro <regebro at gmail.com> wrote:
> On Sun, Jul 26, 2015 at 2:56 AM, Tim Peters <tim.peters at gmail.com> 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.
> Python-Dev mailing list
> Python-Dev at python.org
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev