[Zope] Still. Zope date datatype and TimeZone formatting problems.

[Felipe Barousse Boue]

Zopistas:

I am experiencing the same problem you described by Mr. Hong Yuan in his
post a few from last March.  I have Zope 2.7.4, python 2.3.4 and
PostgreSQL 8.0 and psycopg as DB adapter.

All my dates stores in postgresql are WITHOUT timezone and my linux is
set for the "America/Mexico City" time zone. All works fine at the OS
and python level but not within Zope, it behaves as Mr. Hong Yuan
describes in the post.

I have noticed that Zope, when getting the data coming from postgresql
(the date) always takes it to be at midnight in GMT time zone. 

While formatting the date for presentation, it doesn't take into account
the OS TZ settings, it just assumes data (from postgresql) is at
midnight in GMT and mangles it.

If the TZ variable is set on the zope.conf file, it actually adds hours
to the date (as like moving east), having first during the day having
the "date ok" but a wrong time and, later on the day, the date goes
wrong because of that timezone difference.

If the TZ is not set in the zope.conf file it substracts hours from the
date data from postgresql, effectively moving the date on day before,
because it assumed midnight GMT.

Doing further experiments I have noticed that when the data type passed 
to Zope is "date" (not "datetime" or "timespamp", only date) then Zope 
misbehaves with the TZ, assuming it is on GMT and not taking into
account the overall system (Operating system) time zone settings.

I have seen posts discussing this issue as far back as 2001. Has it been
solved already ?   Is it worth getting into the Zope code and trying to 
fix it and submit a patch ? Or its already deprecated ? or...?

I believe it is still a huge bug the the Zope/Python date time handling
routines, I am correct with this appreciation?

Any comments are most than welcome.

Felipe




> Dieter Maurer wrote:
> 
> >Hong Yaun wrote at 2005-3-14 21:43 +0800:
> >  
> >
> >>...
> >>However, I find that strftime returns a value that is not the same
time 
> >>as the original one, very likely due to some behind-scene timezone 
> >>adjustment, which I don't understand and don't know how to control.
The 
> >>following PythonScript code is an illustration of my problem:
> >>    
> >>
> >
> >A bug recently discussed some time ago in the mailing
> >list. Please search the archive...
> >
> >  
> >
> Thanks Dieter for the pointers. After reading through the thread and
the 
> DateTime code, I finally find that this is a different bug.
> 
> My Linux server has its local time zone set to Asia/Shanghai, which
has 
> the abbreviation 'CST', standing for China Standard Time (GMT+8).
> 
> ws1:~# date
> Thu Mar 17 17:54:08 CST 2005
> 
> Unfortunately, the same abbreviation is also used for US Central 
> Standard Time (GMT-6) and zope takes this as the default. So in python
I 
> get the following test results:
> 
>  >>> from DateTime import DateTime
>  >>> a = DateTime('2005-01-01 17:00')
>  >>> a
> DateTime('2005/01/01 17:00:00 US/Central')
>  >>> a.strftime('%Y-%m-%d %H:%M:%S %Z')
> '2005-01-02 07:00:00 CST'
> 
> In zope version prior to 2.7.4, DateTime.strftime doesn't respect 
> timezone, so I did't see the error in my application. After upgrade
to 
> 2.7.4 however, the difference surfaced.
> 
> By the way, this only happens when I am initializing DateTime object 
> from a string, e.g. from a timestamp field in database. When DateTime
is 
> constructed with the system time, the error doesn't occur:
>  >>> a=DateTime()
>  >>> a
> DateTime('2005/03/17 17:42:36.380 US/Central')
>  >>> a.strftime('%Y-%m-%d %H:%M:%S %Z')
> '2005-03-17 17:42:36 CST'
> 
> How can I fix this?
> 
> -- 
> HONG Yuan
> Homemaster Trading Co., Ltd.
> No. 601, Bldg. 41, 288 Shuangyang Rd. (N)
> Shanghai 200433, P.R.C.
> Tel: +86 21 55056553
> Fax: +86 21 55067325
> E-mail: hongyuan at homemaster.cn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.zope.org/pipermail/zope/attachments/20050522/29ee055a/attachment.bin