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.