[Zope3-dev] Daylight savings unittest errors

[Guido van Rossum]

[Barry P]
> >>I was wondering if anyone had taken a look at a couple items I
> >>filed in the collector 2 weeks ago relating to daylight savings
> >>time, along with patches:
> >>
> >>   http://collector.zope.org/Zope3-dev/159
> >>   http://collector.zope.org/Zope3-dev/160

[Guido]
> > I can't reproduce your test failure of checkFullTimeStamp() in
> > test_timestamp.py.  But looking at the code in _timestamp.c, I get the
> > feeling that it is utterly incomprehensible, so I wouldn't be
> > surprised there's a bug.

[Barry P]
> I don't think the problem is in zodb or zope3 necessarily, I'm starting to 
> think the problem is more in Python itself, or the C library, (or my 
> FreeBSD box could have it's time settings subtly misconfigured).

Right.  Something here is fishy.

> I ran this little bit of Python on Win2k and FreeBSD 4.8 boxes, both
> Python 2.2.3, and both in Central Daylight Time
> 
> -----------------
> import time
> now = 1055176982
> gm = time.gmtime(now)
> 
> print 'original time:', now
> print 'timezone:', time.timezone, 'altzone:', time.altzone, 'daylight:', 
> time.daylight
> print 'gmtime:', gm
> print 'mktime:', time.mktime(gm)
> print 'roundtrip:', (time.mktime(gm) - time.timezone) - now
> ------------------
> 
> Wink2 says:
> ------------
> original time: 1055176982
> timezone: 21600 altzone: 18000 daylight: 1
> gmtime: (2003, 6, 9, 16, 43, 2, 0, 160, 0)
> mktime: 1055198582.0
> roundtrip: 0.0
> -------------

That's what my Linux box says, too, except the second line prints

timezone: 18000 altzone: 14400 daylight: 1

apparently because I'm one US timezone east of you.

> FreeBSD says:
> -------------
> original time: 1055176982
> timezone: 21600 altzone: 18000 daylight: 1
> gmtime: (2003, 6, 9, 16, 43, 2, 0, 160, 0)
> mktime: 1055194982.0
> roundtrip: -3600.0
> -------------
> 
> The last two lines are different, time.mktime() is giving different
> results for the same input.
> 
> Win2k manages to get the result the Zope3 unittests are looking for,
> but I'm not sure FreeBSD is necessarily wrong, given that the Python
> docs for time.mktime() say: "Its argument is ... the time in local
> time, not UTC", which is *not* what we're doing.

The symptom (a roundtrip error of -3600) is consistent with a mktime()
implementation that ignores the tm_isdst flag, and always assumes it
should use DST if the indicated time is in fact in DST, even if
tm_isdst is 0.  I tried this:

    >>> print gm
    (2003, 6, 9, 16, 43, 2, 0, 160, 0)
    >>> print 'roundtrip:', (time.mktime(gm) - time.timezone) - now
    roundtrip: 0.0
    >>> gm1 = gm[:8] + (1,)
    >>> print 'roundtrip:', (time.mktime(gm1) - time.timezone) - now
    roundtrip: -3600.0
    >>> gm2 = gm[:8] + (-1,)
    >>> print 'roundtrip:', (time.mktime(gm2) - time.timezone) - now
    roundtrip: -3600.0
    >>> 

What does it do for you?

> I'd guess that the C library implementation for mktime() is not
> exactly the same in BSD as it is in Windows (or Linux?), which leads
> me to think that perhaps the Python calendar.timegm() function would
> be safer since it avoids the question of timezones alltogether and
> should give the exact same result on all platforms.

Maybe.  But if your mktime() is broken in this fashion, it will break
other Python code too.  I think you should try to get it fixed.

> 	Barry
> 
> (There are daily reports posted to this list from a FreeBSD machine
> running the unittests...what timezone is it running in?)

Dunno.  You seem to be the only person suffering from this; OTOH I
believe I've seen problems with timezones reported froM FreeBSD
systems over the years.

--Guido van Rossum (home page: http://www.python.org/~guido/)