[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. -- https://mail.python.org/mailman/listinfo/python-list