Re: [Zope] Still. Zope date datatype and TimeZone formatting problems.
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 upperbr
dtml-var _.DateTime('2005-05-25')br
dtml-var _.DateTime('2005-05-25') fmt=%d DE %B %Y upperbr
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
[EMAIL PROTECTED] 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
signature.asc
Description: This is a digitally signed message part
___
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 )
Re: [Zope] Still. Zope date datatype and TimeZone formatting problems.
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 upperbr
dtml-var _.DateTime('2005-05-25')br
dtml-var _.DateTime('2005-05-25') fmt=%d DE %B %Y upperbr
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/
[EMAIL PROTECTED] / [EMAIL PROTECTED]
___
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 )
Re: [Zope] Still. Zope date datatype and TimeZone formatting problems.
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 ___ 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 )
[Zope] 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
signature.asc
Description: This is a digitally signed message part
___
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 )
Re: [Zope] Still. Zope date datatype and TimeZone formatting problems.
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/ ___ 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 )
Re: [Zope] Still. Zope date datatype and TimeZone formatting problems.
--On Sonntag, 22. Mai 2005 13:01 Uhr -0500 Felipe Barousse Boue [EMAIL PROTECTED] 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 pgpXaG7IMvUIA.pgp Description: PGP signature ___ 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 )
