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@homemaster.cn