>> ... >> Let z = y - x.o + y.s. >> ... [M.-A. Lemburg] > Care to explain what .o, .n and .s mean for the casual reader ;-) Nope. The casual reader isn't interested enough to be worth the bother. The non-casual reader should read the full proof (at the end of datetimemodule.c or datetime.py), which defines the notation. > ... > I think you are missing a point here: time zones don't have DST. I understand. tzinfo subclasses can, though. The USTimeZone tzinfo subclass posted earlier in this thread, and its 4 instances, was a fully fleshed-out example. >>> from datetime import * >>> t = timetz(3, 15, tzinfo=Eastern) >>> print datetimetz.combine(date(2003, 1, 6), t) 2003-01-06 03:15:00-05:00 >>> print datetimetz.combine(date(2003, 8 ,1), t) 2003-08-01 03:15:00-04:00 >>> As the output shows, Eastern models both EST (-05:00) and EDT (-04:00). astimezone() wants to give sensible (as sensible as possible) results for converting between such hybrid "time zones" too. It's also possible (easy) to create tzinfo subclasses that model only EST, or only EDT, but they seem less useful in real apps. > Each time zone describes a fixed offset from UTC and whenever > the locale applies DST, the time zone for that locale switches > to a new time zone, e.g. MET becomes MEST. The disruption you are > seeing at the DST switch times comes from switching the time zone > and is not caused by the locale's clocks doing a "jump" like in a > Feynman diagram. The disruption exists in real life, and we're allowing for a tzinfo subclass to model it faithfully.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4