My zope application accesses a Postgres table with a timestamp field 'create_date' through ZPsycopgDA and I want to use strftime to format the date the way I like. 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: msg=context.get_some_message t=msgs.create_date print t print t.strftime('%Y-%m-%d %H:%M:%S') return printed When called, the script returns: 2005/03/09 03:36:45 US/Central 2005-03-09 17:36:45 The question is, where does the 'create_date' object get the timezone information for the formatting, and how to achieve my desired output, that is '2005-03-09 03:36:45'? By the way, 'create_date' doesn't seem to be a Zope DateTime object, for when I tested with: t=DateTime() print t print t.strftime('%Y-%m-%d %H:%M:%S') The two prints give the same time value. For your information, in my ZPsycopgDA property, I have choosen the option: 'Use Zope's internal DateTime module (instead of mxDateTime)'. My zope version: 2.7.4 under Linux. Thanks for your help. Hong Yuan
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... -- Dieter
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
Hong Yuan wrote at 2005-3-17 18:02 +0800:
... My Linux server has its local time zone set to Asia/Shanghai, which has the abbreviation 'CST', standing for China Standard Time (GMT+8). ... Unfortunately, the same abbreviation is also used for US Central Standard Time (GMT-6) and zope takes this as the default.
A nice problem: using the same abbreviation for different time zones...
... How can I fix this?
The easiest way would be to use a different (and unique) notation for your timezone, e.g. "GMT+8". If this is not an option, you will need to change Zope's interpretation of "CST" -- either by changing its code directly or by a so called "MonkeyPatch" (you should find information about monkey patching on Zope.org). -- Dieter
... How can I fix this?
The easiest way would be to use a different (and unique) notation for your timezone, e.g. "GMT+8".
Well, it turns out not to be so easy. I found that even a notation like "GMT+8" is not unique in meaning, see http://docs.sun.com/app/docs/doc/806-5189/6je7g4sr7?a=view. It can mean 8 hours east of GMT, or 8 hours west of GMT!!! And again zope DateTime seems to interprete this differently than the Linux operation system. With my operation system timezone now set to Etc/GMT-8: ws1:/usr/lib/zope2.7/lib/python# date Fri Mar 18 10:49:44 GMT-8 2005 ws1:/usr/lib/zope2.7/lib/python# cat /etc/timezone Etc/GMT-8 I now get:
from DateTime import DateTime a= DateTime('2005/01/01 08:00 GMT-8') a DateTime('2005/01/01 08:00:00 GMT-8') a.strftime('%Y-%m-%d %H:%M:%S %Z') '2005-01-02 00:00:00 GMT-8'
Isnt' that very confusing? Instead of the 14 hours off with CST, I now get 16 hours off! If zope interpretes the timezone abbreviation differently than the operation system, it will causer the users/developers a lot of headache. I think this could be called a bug now instead of just a nusance. For the moment, I have to switch to Date() and Time() instead of strftime. -- 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
On Fri, 18 Mar 2005 11:26:51 +0800, Hong Yuan <hongyuan@homemaster.cn> wrote:
... How can I fix this?
The easiest way would be to use a different (and unique) notation for your timezone, e.g. "GMT+8".
Well, it turns out not to be so easy. I found that even a notation like "GMT+8" is not unique in meaning, see http://docs.sun.com/app/docs/doc/806-5189/6je7g4sr7?a=view. It can mean 8 hours east of GMT, or 8 hours west of GMT!!! And again zope DateTime seems to interprete this differently than the Linux operation system.
That doesn't sound right, I'm 99% sure that GMT+8 is 8 hours ahead of GMT, to the east of the meridian, whereas GMT-8 is 8 hours behind, to the west. Here in New Zealand we are on GMT+13, and we're certainly east. Chances are that the doc refers to some Solaris quirk. Blame Sun. -- Phillip Hutchings http://www.sitharus.com/ sitharus@gmail.com / sitharus@sitharus.com
Phillip Hutchings wrote:
That doesn't sound right, I'm 99% sure that GMT+8 is 8 hours ahead of GMT, to the east of the meridian, whereas GMT-8 is 8 hours behind, to the west. Here in New Zealand we are on GMT+13, and we're certainly east.
Chances are that the doc refers to some Solaris quirk. Blame Sun.
Seems this is the defined behavior of Posix, not Sun. Quoting from http://www.twinsun.com/tz/tz-link.htm: Numeric time zone abbreviations typically count hours east of UTC, e.g., |+09| for Japan and |-10| for Hawaii. However, the POSIX |TZ| environment variable uses the opposite convention. For example, one might use |TZ="JST-9"| and |TZ="HST10"| for Japan and Hawaii, respectively. If the |tz| database is available, it is usually better to use settings like |TZ="Asia/Tokyo"| and |TZ="Pacific/Honolulu"| instead, as this should avoid confusion, handle old timestamps better, and insulate you better from any future changes to the rules. One should never set POSIX |TZ| to a value like |"GMT-9"|, though, since this would falsely claim that local time is nine hours ahead of UTC and the time zone is called "GMT". And please take a look at http://twiki.org/cgi-bin/xtra/tzdate, which says: *Greenwich Mean Time: (GMT/UCT/UTC/Universal/Zulu; positive numbers count hours west of GMT) * For China, it says: Timezone: Etc/GMT-8 Date&time: Fri, 18 Mar 2005 13:57:30 +0800 (GMT-8) Seems there is a lot of history and chaos behind the timezone definition. -- 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
Hong Yuan wrote at 2005-3-18 11:26 +0800:
... [DM]
The easiest way would be to use a different (and unique) notation for your timezone, e.g. "GMT+8".
Well, it turns out not to be so easy. I found that even a notation like "GMT+8" is not unique in meaning, see http://docs.sun.com/app/docs/doc/806-5189/6je7g4sr7?a=view. It can mean 8 hours east of GMT, or 8 hours west of GMT!!! And again zope DateTime seems to interprete this differently than the Linux operation system.
Apparently, it is very simple to make simple things extremely complex... I noted a second option in my previous message -- this you see it? -- Dieter
What is simple for you may be complex for others. I think that is the essence of this forum, to share your wealth of knowledge and experience with the less priviledge. kamal. At 08:34 PM 3/18/2005 +0100, Dieter Maurer wrote:
Hong Yuan wrote at 2005-3-18 11:26 +0800:
... [DM]
The easiest way would be to use a different (and unique) notation for your timezone, e.g. "GMT+8".
Well, it turns out not to be so easy. I found that even a notation like "GMT+8" is not unique in meaning, see http://docs.sun.com/app/docs/doc/806-5189/6je7g4sr7?a=view. It can mean 8 hours east of GMT, or 8 hours west of GMT!!! And again zope DateTime seems to interprete this differently than the Linux operation system.
Apparently, it is very simple to make simple things extremely complex...
I noted a second option in my previous message -- this you see it?
-- Dieter _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.4 - Release Date: 3/18/2005
-- Internal Virus Database is out-of-date. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.4 - Release Date: 3/18/2005
participants (5)
-
Dieter Maurer -
Hamzat Kamal -
Hong Yaun -
Hong Yuan
-
Phillip Hutchings