And I would want to remind everyone again that this is not a question of the problem being impossible. It's just really complex to get right in all cases, and that always having the UTC timestamp around gets rid of most of that complexity.
On Sat, Jul 25, 2015 at 3:39 AM, Tim Peters firstname.lastname@example.org wrote:
[ISAAC J SCHWABACHER email@example.com]
... I disagree with the view Tim had of time zones when he wrote that comment (and that code). It sounds like he views US/Eastern and US/Central as time zones (which they are), but thinks of the various America/Indiana zones as switching back and forth between them, rather than being time zones in their own right
You can think of them anyway you like. The point of the code was to provide a simple & efficient way to convert from UTC to local time in all "time zones" in known actual use at the time; the point of the comment was to explain the limitations of the code. Although, as Allexander noted, the stated assumptions are stronger than needed.
I think the right perspective is that a time zone *is* the function that its `fromutc()` method implements,
Fine by me ;-)
although of course we need additional information in order to actually compute (rather than merely mathematically define) its inverse. Daylight Saving Time is a red herring,
Overstated. DST is in fact the _only_ real complication in 99.99% of time zones (perhaps even 99.9913% ;-) ). As the docs say, if you have some crazy-ass time zone in mind, fine, that's why fromutc() was exposed (so your; crazy-ass tzinfo class can override it).
and assumptions 2 and 4
Nitpick: 4 is a consequence of 2, not an independent assumption.
in that exposition are just wrong from this point of view.
As above, there is no particular POV in this code: just a specific fromutc() implementation, comments that explain its limitations, and an invitation in the docs to override it if it's not enough for your case.
In the worst case, Asia/Riyadh's two years of solar time completely shatter these assumptions.
Sure. But, honestly, who cares? Riyadh Solar Time was so off-the-wall that even the Saudis gave up on it 25 years ago (after a miserable 3-year experiment with it). "Practicality beats purity".
[eliding a more-general view of what time zones "really" are]
I'm not eliding it because I disagree with it, but because time zones are political constructions. "The math" we make up may or may not be good enough to deal with all future political abominations; for example:
... This assumption would be violated if, for example, some jurisdiction decided to fall back two hours by falling back one hour and then immediately falling back a second hour. I recommend the overthrow of any such jurisdiction and its (annexation by the Netherlands).
That's not objectively any more bizarre than Riyadh Solar Time. Although, if I've lived longer than you, I may be more wary about the creative stupidity of political schemes ;-)
... (Lennart, I think this third assumption is the important part of your "no changes within 48 hours of each other" assumption,
The "48 hours" bit came from Alexander. I'm personally unclear on what Lennart's problems are.
... All of these computations can be accomplished by searches of ordered lists and applications of $fromlocal_i$.
Do you have real-world use cases in mind beyond supporting long-abandoned Riyadh Solar time?
... With this perspective, arithmetic becomes "translate to UTC, operate, translate back", which is as it should be.
There _was_ a POV in the datetime design about that: no, that's not how it should be. Blame Guido ;-) If I add, say, 24 hours to noon today, I want to get noon tomorrow, and couldn't care less whether DST started or stopped (or any other political adjustment was made) in between. For that reason, it was wholly intentional that datetime + timedelta treats datetime as "naive". If that's not what someone wants, fine, but then they don't want Python's datetime arithmetic BTW, there's no implication that they're "wrong" for wanting something different; what would be wrong is insisting that datetime's POV is "wrong". Both views are valid and useful, depending on the needs of the application. One had to picked as the built-in behavior, and "naive" won.
... But IIUC what Lennart is complaining about
I don't, and I wish he would be more explicit about what "the problem(s)" is(are).
is the fact that the DST flag isn't part of and can't be embedded into a local time, so it's impossible to fold the second parameter to $fromlocal$ into $t$. Without that, a local time isn't rich enough to designate a single point in time and the whole edifice breaks.
You can blame Guido for that too ;-) , but in this case I disagree(d) with him: Guido was overly (IMO) annoyed by that the only apparent purpose for a struct tm's tm_ isdst flag was to disambiguate local times in a relative handful of cases. His thought: an entire bit just for that?! My thought: get over it, it's one measly bit.
my-kingdom-for-bit-ingly y'rs - tim