On Wed, Mar 08, 2000 at 10:53:54AM -0800, Michel Pelletier wrote:
We need a couple more data points before we can blame Zope for this or understand possibly what is happening. Can any one else verify and reproduce CURTIS David's problem?
I just came across the same problem when playing with ZNavigator: When I add NavItems to a ZNavigator, their "publish date" seems to be off by one hour, i.e. the item remains unvisible until one hour after I created it. The publish date (which is by default set to the creation date) looked correct--until I noticed that it used a wrong timezone: E.g. the publish date is set to "2000/04/24 22:35:43.4558 GMT+1", although it should be "GMT+2": freefly;7> date Mon Apr 24 22:35:18 CEST 2000 freefly;8> date -R Mon, 24 Apr 2000 22:35:22 +0200 freefly;9> date --utc Mon Apr 24 20:35:24 UTC 2000 This machine is running Debian potato (libc6 2.1); its timezone is set to Europe/Berlin. Europe/Berlin is CET (==GMT+1) normally, but CEST (==GMT+2) during daylight saving times, as currently. It took me some time to notice that the reason for this problem is a severe design flaw in DateTime: Whenever DateTime uses time.gmtime or time.localtime to 'render' a date, it simply drops the daylight savings flag from the result (like in "gmtime[:6]" or in "tzname[0]"). The effect is that it records the daylight saving date (in hour, minute etc.) but the normal (non-daylight) timezone (according to tzname[0]) in _tz. The result: freefly;133> cd /usr/lib/zope/lib/python/ freefly;134> python Python 1.5.2 (#0, Apr 3 2000, 14:46:48) [GCC 2.95.2 20000313 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
import time from DateTime import DateTime t=time.time() now=DateTime(t) gmt=DateTime(t,'GMT') gmt1=DateTime(t,'GMT+1') now==gmt==gmt1 1 gmt DateTime('2000/04/24 19:33:24.1498 GMT') gmt1 DateTime('2000/04/24 20:33:24.1498 GMT+1') now DateTime('2000/04/24 21:33:24.1498 GMT+1')
i.e. internally the date (_t) is handled correctly, but the rendering of the date is wrong, since it relies on the representation in hour, minute and _tz. To fix this, DateTime must recognize the daylight savings flag. Furthermore, _localzone really does depend on the argument: I.e. on the system above, for a date in winter, _localzone would correspond to GMT+1, while for a date in summer it would correspond to GMT+2! The current design implies that _localzone is always the on that given machine. I will also submit this into the Collector. Gregor