Still. Zope date datatype and TimeZone formatting problems.
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
Mixing things that have timezone and things that doesn't can always be tricky. The hard part is identifying exactly how you expect things to behave at each step, and then making sure it does. In this case it seems like data written to postgres is not donverted to GMT, but stripped of the timezone, but when read, it is assumed to be GMT. This is inconsistent. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
--On Sonntag, 22. Mai 2005 13:01 Uhr -0500 Felipe Barousse Boue <fbarousse@piensa.com> wrote:
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.
I believe it is still a huge bug the the Zope/Python date time handling routines, I am correct with this appreciation?
I am pretty sure that this is a problem of the underlaying DA (ZPsycopgDA) or the under-underlaying psycopg Python module. DateTime instances are generated by DA from the data coming out of the database...so I would look there and maybe check with the author of the DA. So try to search the solution from the bottom and not from the top. -aj
Andreas/Tino: Thanks for your replies regarding this date and timezones issue. (Thanks Dieter Maurer for previous opinions also) It has been a long and tedious problem to chase and debug, here it goes what I have narrowed so far: Let's forget about the undelying DA, the database has nothing to do with it. The same problem happens when: 1) Using _.DateTime(datestring) 2) The datestring has minus-sign as year, month, date separators. 3) A format is applied, like fmt="%d DE %B %Y" The following are examples when viewing a DTML Document containing : <dtml-var "_.DateTime('2005-05-25')"><br> <dtml-var "_.DateTime('2005/05/25')" fmt="%d DE %B %Y" upper><br> <dtml-var "_.DateTime('2005-05-25')"><br> <dtml-var "_.DateTime('2005-05-25')" fmt="%d DE %B %Y" upper><br> Output is: 2005/05/25 25 DE MAYO 2005 2005/05/25 24 DE MAYO 2005 Look at the last one 24 DE MAYO 2005, that is wrong ! In the last case, Zope assumes the date to be at midnight GMT and then, when I apply the formatting (fmt="%d DE %B %Y") it substracts 5 hours from GMT to get to my local timezone, resulting the date is 1 day off the real date. I think Zope should not assume that a date is in any particular time zone, nor in midnight GMT when using minus-signs as separators, rather it should take the system's time zone settings into account when applying datetime formatting. Therefore, if there's the need to use dashes, there should be no reason to explicit state a time zone when the user is only entering a simple date (year, month, day). In other words, why using dashes is acting like a bug, instead of working like the first casem using "/" as separator ? Guess I hit the jackpot with a Zope bug...who agrees? Your comments are appreciated, thanks in advance. ! Felipe On Mon, 2005-05-23 at 07:08 +0200, Andreas Jung wrote:
--On Sonntag, 22. Mai 2005 13:01 Uhr -0500 Felipe Barousse Boue <fbarousse@piensa.com> wrote:
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.
I believe it is still a huge bug the the Zope/Python date time handling routines, I am correct with this appreciation?
I am pretty sure that this is a problem of the underlaying DA (ZPsycopgDA) or the under-underlaying psycopg Python module. DateTime instances are generated by DA from the data coming out of the database...so I would look there and maybe check with the author of the DA. So try to search the solution from the bottom and not from the top.
-aj
The same problem happens when:
1) Using _.DateTime(datestring) 2) The datestring has minus-sign as year, month, date separators. 3) A format is applied, like fmt="%d DE %B %Y"
The following are examples when viewing a DTML Document containing :
<dtml-var "_.DateTime('2005-05-25')"><br>
<dtml-var "_.DateTime('2005/05/25')" fmt="%d DE %B %Y" upper><br>
<dtml-var "_.DateTime('2005-05-25')"><br>
<dtml-var "_.DateTime('2005-05-25')" fmt="%d DE %B %Y" upper><br>
Output is:
2005/05/25 25 DE MAYO 2005 2005/05/25 24 DE MAYO 2005
Look at the last one 24 DE MAYO 2005, that is wrong !
In the last case, Zope assumes the date to be at midnight GMT and then, when I apply the formatting (fmt="%d DE %B %Y") it substracts 5 hours from GMT to get to my local timezone, resulting the date is 1 day off the real date.
The hyphen-delimited Y-m-d format is an ISO standard, ISO 8601, and is therefore always in UTC. You'll need to specify it as 2005-05-25T00-05 for 5 hours before.
I think Zope should not assume that a date is in any particular time zone, nor in midnight GMT when using minus-signs as separators, rather it should take the system's time zone settings into account when applying datetime formatting. Therefore, if there's the need to use dashes, there should be no reason to explicit state a time zone when the user is only entering a simple date (year, month, day).
In other words, why using dashes is acting like a bug, instead of working like the first casem using "/" as separator ?
Because it's not a bug, you're specifying an ISO 8601 date with no timezone qualifier, so it's assuming UTC, just like the spec says. I'm not claiming that the behaviour is what people want, but as long as Zope interprets ISO 8601 by the standard, then this isn't really a bug. -- Phillip Hutchings http://www.sitharus.com/ sitharus@gmail.com / sitharus@sitharus.com
Am Sonntag, den 22.05.2005, 13:01 -0500 schrieb 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.
Of course. I wonder why it should? Otoh, did you try to give the timezone you want when you select the data?
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.
I assume this setting is mainly for zope generated datetime objects, not something you read from a DB.
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.
Well, databases are often on a seperate host. How should zope guess in this case? If it would, I guess someone else would complaint ;)
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?
Well, zopes DateTime implemenataion has some (serious) limits. But I dont think it should really be blamed for the above problems. Maybe some workarounds can be made in the psycopg driver. What btw. happens if you use mxdatetime instead of the zope builtin? Psycopg has this as configuration option. Regards Tino
participants (5)
-
Andreas Jung -
Felipe Barousse Boue -
Lennart Regebro -
Phillip Hutchings -
Tino Wildenhain