[Zope3-dev] Daylight savings unittest errors

[Barry Pederson]

Guido van Rossum wrote:

> 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 get -3600.0 for all three cases (0, 1, -1) for the last element in the 
tuple.

So I guess you're right, it's assuming DST even if we pass a 0 - although 
in a sense we're *lying* when we're telling it a date in June on this 
machine isn't DST, when it knows that it is.

Both the POSIX and BSD manpages for mktime are a bit weird about this 
detail, basically:

      A ... zero value for tm_isdst causes mktime() to presume initially
      that summer time (for example, Daylight Saving Time)... is not in
      effect for the specified time,

"presume initially"?  Sounds like another way of saying "hint", where an 
implementation doesn't necessarily have to pay attention to it if it knows 
better.



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

I agree if it's wrong it should be fixed ...but... even if someone was to 
convince the BSD people that their mktime() was broke, and future versions 
were fixed - that doesn't help existing boxes that may try to run Zope3, 
and find weird stuff happening like cookies expiring an hour before they're 
supposed to.

My take is that: Python code that's feeding GMT/UTC into time.mktime() 
[against the advice of the Python docs] and then tries to adjust for the 
local timezone manually, instead of using another function that's meant 
specifically for that exact job and isn't affected by potential underlying 
platform problems - is a bit whacked and could also be fixed.

	Barry