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