Re: [Zope] Z2.log and Date stamps 2nd Call for answers????
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? -Michel CURTIS David wrote:
Friends of Zope,
My Z2.log file entries which are in the /var/Z2.log are inconsistent with the actual system time. The Z2.log file shows 123.123.123.123 [08/Mar/2000:16:49:40-0700]
The actual system time is 8:49 pacific time. NT 4.0 show (GMT-0800 UTC) Pacific time (US and Canada);Tijuana It and is set to automatically adjust for daylight saving time.
I have a NT 4.0 windoze workstation machine that is running Zope latest version 2.1.4. and of course python 1.5.2.
Is there a script file that needs adjusting to make the file log correctly? I know that -700 is UTC is Mountain Standard Time. Do Zope programmers like the warm southern climate better than the cold climates? In short can this "default" be changed.
! !
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
In article <38C6A1C2.C8FD4053@digicool.com>, Michel Pelletier <michel@digicool.com> writes
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?
Me too. I mentioned this problem several months ago on this list. I now just take my log files and run it thru a script to correct the time problem, and also do the reverse DNS lookup. ------- Regards, Graham Chiu gchiu<at>compkarori.co.nz http://www.compkarori.com/dynamo - The Homebuilt Dynamo http://www.compkarori.com/dbase - The dBase bulletin
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
participants (3)
-
Graham Chiu -
Gregor Hoffleit -
Michel Pelletier