[Datetime-SIG] Are there any "correct" implementations of tzinfo?
Laura Creighton
lac at openend.se
Sun Sep 13 16:31:29 EDT 2015
In a message of Sun, 13 Sep 2015 15:13:53 -0500, Tim Peters writes:
>[Laura]
>> Via Rail will give you a schedule when you book your tickets. But I
>> am wrong, it gives it to you in local time, which you can scrape or
>> even use the via rail api. So it is the person getting off in
>> Creighton who wants to tell his relatives back in Halifax what
>> time he is arriving (in their time) (so they can call him and
>> avoid the hellish hotel surtax on long distance calls) who will
>> have the problem.
>
>Whatever time zone the traveler's railroad schedule uses, so long as
>it sticks to just one
This is what does not happen. Which is why I have written a python
app to perform conversions for my parents, in the past.
>But there's nothing new here: datetime has been around for a dozen
>years already, and nobody is proposing to add any new basic
>functionality to tzinfos. PEP 495 is only about adding a flag to
>allow correct conversion of ambiguous local times (typically at the
>end of DST, when the local clock repeats a span of times) to UTC. So
>if this were a popular use case, I expect we would already have heard
>of it. Note that Python zoneinfo wrappings are already available via,
>at least, the pytz and dateutil packages.
I am a happy user of pytz. On the other hand, I think this means that
my brain has gone through some sort of non-reversible transformation
which makes me accurate, but not exactly sane on the issue.
I think I have misunderstood Alexander Belopolsky as saying that
datetime had functionality which I don't think it has. Thus I thought
we must be planning to add some functionality here. Sorry about this.
However, people do need to be aware, if they are not already, that
people with 3 times in 3 different tz will want to sort them. Telling
them that they must convert them to UTC before they do so is, in my
opinion, a very fine idea. Expecting them to work this out by themselves
via a assertion that the comparison operator is not transitive, is,
I think, asking a lot of them.
Laura
More information about the Python-list
mailing list