[Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Tim Peters]

[Laura]
>>> But I am not sure how it is that a poor soul who just wants to print a
>>> railway schedule 'in local time' is supposed to know that Creighton is
>>> using Winnipeg time.

[Tim]
>> I'm not sure how that poor soul would get a railway schedule
>> manipulable in Python to begin with ;-)

[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 the traveler subtracts the departure time from
the arrival time to determine how long the trip takes.  They add that
to the Halifax time at which they depart, and tell their Halifax
relatives the result.  They don't need to know anything about the
destination's time zone to do this, unless a daylight transition
occurs between departure and arrival, and the schedule itself
remembered to account for it.  In which case, pragmatically, they can
just add an hour "to be safe" ;-)


> And this is the sort of use case I think we will see a lot of.

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.