[Zope] strftime and timezone

[Hong Yuan]

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