Gentlepeople, Section 8.1.6 of the library manual talks about utcoffset(dt)-dst(dt) as the "standard offset" and says that this should not depend on the date or time but only on the location. That seems to assume that the politicians who change timezone rules only change the times when DST is in effect, but don't meddle with the standard offset. Often that is true, at least so long as you don't go all that far into the past. But not always. Consider Venezuela, which changed from standard offset -4:00 to -4:30 in 2007, or Samoa, which is changing from -11:00 to +13:00 end of this year. For that matter, various parts of Indiana seem to be switching from time to time, as recently as a couple of years ago. Admittedly this is not all that sane, but then again it's politics. If datetime.astimezone() relies on this assumption when it's clearly not always satisfied, what goes wrong? See the Olson database for all the gory details; the examples I quoted all can be found in there. paul
On Sun, Sep 18, 2011 at 09:04:16PM -0400, Paul Koning wrote:
Gentlepeople,
Section 8.1.6 of the library manual talks about utcoffset(dt)-dst(dt) as the "standard offset" and says that this should not depend on the date or time but only on the location.
What would be good note to add to explain that? IIRC, someone at the top when dealing with datetime and timezones Python docs already mentions that it cannot be relied up completely, because timezone rules changes sometimes due to politics of the land. -- Senthil
On Sep 28, 2011, at 7:49 PM, Senthil Kumaran wrote:
On Sun, Sep 18, 2011 at 09:04:16PM -0400, Paul Koning wrote:
Gentlepeople,
Section 8.1.6 of the library manual talks about utcoffset(dt)-dst(dt) as the "standard offset" and says that this should not depend on the date or time but only on the location.
What would be good note to add to explain that? IIRC, someone at the top when dealing with datetime and timezones Python docs already mentions that it cannot be relied up completely, because timezone rules changes sometimes due to politics of the land.
-- Senthil
I would just get rid of that statement, because it isn't supported by the reality of how timezones are defined. The larger question is in the doc's claim that datetime.astimezone() relies on this assumption. Does it really? If yes, why? Given that the assumption is not valid, is astimezone() in fact broken? That's possibly a code issue rather than a doc issue (if the doc correctly stated the dependence). paul
On Sep 28, 2011, at 7:49 PM, Senthil Kumaran wrote:
On Sun, Sep 18, 2011 at 09:04:16PM -0400, Paul Koning wrote:
Gentlepeople,
Section 8.1.6 of the library manual talks about utcoffset(dt)-dst(dt) as the "standard offset" and says that this should not depend on the date or time but only on the location.
What would be good note to add to explain that? IIRC, someone at the top when dealing with datetime and timezones Python docs already mentions that it cannot be relied up completely, because timezone rules changes sometimes due to politics of the land.
I think the documentation is wrong here. I did a simple test (using the pytz module which implements the Olson timezone database), using datetime.astimezone() to change from US Eastern time to Venezuela time. Venezuela changed its standard offset from -4:00 to -4:30 in 2007. The answer is that it works correctly -- you can see this by doing the experiment once with a date in 2006, and once with a date in a later year (like 2011). So I think what's needed is to delete this entire block of text from the description of the tzinfo.dst method: -------- An instance tz of a tzinfo subclass that models both standard and daylight times must be consistent in this sense: tz.utcoffset(dt) - tz.dst(dt) mustreturnthesameresultforeverydatetimedtwithdt.tzinfo == tzForsanetzinfosubclasses, this expression yields the time zone’s “standard offset”, which should not depend on the date or the time, but only on geographic location. The implementation of datetime.astimezone() relies on this, but cannot detect violations; it’s the programmer’s responsibility to ensure it. If a tzinfo subclass cannot guarantee this, it may be able to override the default implementation of tzinfo.fromutc() to work correctly with astimezone() regardless. --------- because it is not true -- astimezone() works right. It might also be useful to add to the description of the tzinfo.utcoffset() method to point out that the examples given are simplified and apply only if the base offset is indeed constant, which is true for some timezones (like US Eastern) but not others (like Venezuela). paul
participants (2)
-
Paul Koning -
Senthil Kumaran