I'm pretty sure this issue has been discussed before (searching for DateTime brings up a lot of hits). However I would like to point to a potential fix for the problem of Zope's DateTime library not being able to tell the difference between US/Eastern and Aus/East. https://bugs.launchpad.net/zope2/+bug/142148 At the end of the bug I've linked to above, I've submitted a patch that appears to have fixed the issue on my two zope installs without having to hack up the tznames in anyway. Oh and hi, I'm James. -- James Purser <james@jamespurser.com.au>
--On 18. Dezember 2007 13:26:07 +1100 James Purser <james@jamespurser.com.au> wrote:
I'm pretty sure this issue has been discussed before (searching for DateTime brings up a lot of hits). However I would like to point to a potential fix for the problem of Zope's DateTime library not being able to tell the difference between US/Eastern and Aus/East.
https://bugs.launchpad.net/zope2/+bug/142148
At the end of the bug I've linked to above, I've submitted a patch that appears to have fixed the issue on my two zope installs without having to hack up the tznames in anyway.
Sorry but this patch is poor (the "if False" clause makes no sense) and it does not have tests. -aj
On Tue, 2007-12-18 at 05:32 +0100, Andreas Jung wrote:
Sorry but this patch is poor (the "if False" clause makes no sense) and it does not have tests.
-aj
No worries, I'm new to Python in general so I'm going to accept any corrections. However I believe that that is the section that is causing the issues, and if Falsing it hasn't produced any noticable bugs, problems with the system. I am more than willing to look at creating a patch that conforms if people indicate that the general approach (removing the assignment) is acceptable. -- James Purser <james@jamespurser.com.au>
--On 18. Dezember 2007 15:46:06 +1100 James Purser <james@jamespurser.com.au> wrote:
On Tue, 2007-12-18 at 05:32 +0100, Andreas Jung wrote:
Sorry but this patch is poor (the "if False" clause makes no sense) and it does not have tests.
-aj
No worries, I'm new to Python in general so I'm going to accept any corrections. However I believe that that is the section that is causing the issues, and if Falsing it hasn't produced any noticable bugs, problems with the system.
I am more than willing to look at creating a patch that conforms if people indicate that the general approach (removing the assignment) is acceptable.
It needs a unittest in the first place. Untested code or untested patches are not acceptable for people applying patches if one can not determine what problem a particular patch is solving. -aj
How does other software handle this? pytz, most importantly? I found a bug report in Java about the same thing, and they said "use another name", i.e. Australia/Eastern or AEST, which are both unambiguous. And how does Brazilians solve it? They also have an EST.
OK, I have looked HARD at this now. And dateutil.tz solves this. I don't think Zope can solve this with pytz, unless we implement the same solution in pytz as already exists in dateutil.tz. It solves it by implementing a tzinfo class that wraps zoneinfo files, and that way you simply wrap /etc/localtime and get the right info. I have tried the suggested solution of matching TZ names and offsets and it doesn't work, becuase you'll end up in the correct time zone but not in the correct location, and hence not with the correct daylight saving. More info: http://regebro.wordpress.com/2007/12/18/python-and-time-zones-fighting-the-b... -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64
participants (3)
-
Andreas Jung -
James Purser -
Lennart Regebro