[Zope] Z2.log and Date stamps 2nd Call for answers????

[Gregor Hoffleit]

--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

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":
 =20
  freefly;7> date
  Mon Apr 24 22:35:18 CEST 2000
  freefly;8> date -R=20
  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 (=3D=3DGMT+1) normally, but CEST (=3D=
=3DGMT+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=3Dtime.time()
  >>> now=3DDateTime(t)
  >>> gmt=3DDateTime(t,'GMT')
  >>> gmt1=3DDateTime(t,'GMT+1')
  >>> now=3D=3Dgmt=3D=3Dgmt1
  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')
  >>>=20

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 _t=
z.


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

--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5BLaM3eVfDf25G40RAXXUAKCaP6npKoYGoKRchkW/j2f6XaKLWwCeJA+u
HVcON24xAujOfKWLoMTUlyk=
=YiXO
-----END PGP SIGNATURE-----

--FL5UXtIhxfXey3p5--