[Zope3-dev] Daylight savings unittest errors

[Barry Pederson]

Guido van Rossum wrote:
>>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
> 
> 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.

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).

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
-------------

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.

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.

	Barry

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