Marc-Andre Lemburg <m...@egenix.com> added the comment: Amaury Forgeot d'Arc wrote: > > The error comes from the way Python computes timezone and daylight: it > queries the tm_gmtoff of two timestamps, one close to the first of January, > the other close to the first of July. But last January the previous > definition of the timezone was still in force... and indeed, when I changed > the code to use *next* January instead, I have the expected values. > > Is there an algorithm that gives the correct answer? Taking the 1st of > January closest to the current date would not work either. Or is there > another way (in portable C) to approach timezones?
A fairly "correct" way is to query the time zone database at time module import time by using the DST and GMT offset of that time. IMO time.timezone and time.daylight should be deprecated since they will give wrong results around DST changes (both switch times and legal changes such as the described one) in long running processes such as daemons. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13466> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
