insane Central Daylight Time, Zope 2.2.2
Most of the central US just went to daylight savings time last night and my Zope 2.2.2 installation seems to have decided to use UTC+2 instead of CDT (which is UTC-5). If I telnet into the server and check for the time, Linux gives me the correct date and time. I'll go looking for the problem now, but thought some of you may want to check if you have a similar wrinkle in time. The server is physically in the Eastern US time zone, we run it on Central Time, and I'm currently on Bangkok time (UTC+9). No wonder Zope is confused :-) -- Dennis Nichols nichols@tradingconnections.com
At 4/1/2001 06:53 PM, Dennis Nichols wrote:
Most of the central US just went to daylight savings time last night and my Zope 2.2.2 installation seems to have decided to use UTC+2 instead of CDT (which is UTC-5).
Replying to myself... I first tried installing the DateTime.py from 2.3.1 into my 2.2.2 installation, but that did not help (I had already verified that DateTimeZone.py had not changed between the two versions). Then I tried reading DateTimeZone.py but that made my head hurt. So I read DateTime.py instead. There I found that CDT, which is what my Linux says when you ask it for the time, is defined as GMT+2. I don't know what eastern European time zone that is supposed to be, but I reclaimed it for my own by changing the source to GMT-5 (reluctantly, since I have no clue about the part that DateTimeZone.py plays in this). So that's where it's going to stay until I get motivated to do it right or somebody explains it/beats me to it. -- Dennis Nichols nichols@tradingconnections.com
Most of the central US just went to daylight savings time last night and my Zope 2.2.2 installation seems to have decided to use UTC+2 instead of CDT (which is UTC-5).
Replying to myself... I first tried installing the DateTime.py from 2.3.1 into my 2.2.2 installation, but that did not help (I had already verified that DateTimeZone.py had not changed between the two versions). Then I tried reading DateTimeZone.py but that made my head hurt. So I read DateTime.py instead. There I found that CDT, which is what my Linux says when you ask it for the time, is defined as GMT+2. I don't know what eastern European time zone that is supposed to be, but I reclaimed it for my own by changing the source to GMT-5 (reluctantly, since I have no clue about the part that DateTimeZone.py plays in this).
So that's where it's going to stay until I get motivated to do it right or somebody explains it/beats me to it.
:( The problem is that DT is probably trying to do too much with magical timezone recognition. At some point, some bonehead (and I suspect it probably was me) accepted a request to add CDT to the mapping without noticing that it is a good example of an ambiguous timezone name. The problem now is how to fix it - we could change it to mean 'CDT' (american central daylight time), but I suspect I'll then get another bug report from somewhere in Europe telling me that now its broken for them :( One option I've thought about is to have a bit of code in DateTime.py that runs at import time, which tries to fix any ambiguous names in light of the actual machine's timezone info. For example, if time.tzname is ('CST', 'CDT'), we could use time.timezone and time.altzone to ensure that the mapping is right for those values, overriding any defaults in the mapping. Of course, the big flaw in that plan is that in some cases the machine may not be physically in the timezone that you are interested in - if that is the case, the above solution won't work. Another, less elegant option would be to have DateTime attempt to import some well-known module name (like 'TimeZoneInfo'), which is not actually distributed with Zope (and fail quietly if it can't be imported). If such a module were found, DT would be willing to merge / override that explicit zone info into the timezone mapping. This would allow people who have issues with the defaults to provide a way to override them without having to hack DateTime each time they upgrade. Thoughts? Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
At 4/10/01 11:09 AM, Brian Lloyd wrote:
:( The problem is that DT is probably trying to do too much with magical timezone recognition. At some point, some bonehead (and I suspect it probably was me) accepted a request to add CDT to the mapping without noticing that it is a good example of an ambiguous timezone name.
Not a solution, but for part of the history, see http://lists.zope.org/pipermail/zope-dev/1999-April/000323.html where Martijn Pieters writes about a change to DT -- Dennis Nichols nichols@tradingconnections.com
:( The problem is that DT is probably trying to do too much with magical timezone recognition. At some point, some bonehead (and I suspect it probably was me) accepted a request to add CDT to the mapping without noticing that it is a good example of an ambiguous timezone name.
Not a solution, but for part of the history, see http://lists.zope.org/pipermail/zope-dev/1999-April/000323.html where Martijn Pieters writes about a change to DT
Hmm - ok then, (because there is no specific defender of 'CDT' - the mapping was copied from some perl library) I propose to just remove it altogether (in which case the right thing should happen for both cases). Could you do a quick test and verify if things are sane for you if 'CDT' is simply removed from the mapping? Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
On Wed, 11 Apr 2001, Brian Lloyd wrote:
Could you do a quick test and verify if things are sane for you if 'CDT' is simply removed from the mapping?
Hey, wait a minute. *I'm* in CDT. Doesn't it just need to be redefined? -Tim -- Tim Wilson | Visit Sibley online: | Check out: Henry Sibley HS | http://www.isd197.k12.mn.us/ | http://www.zope.org/ W. St. Paul, MN | | http://slashdot.org/ wilson@visi.com | <dtml-var pithy_quote> | http://linux.com/
Could you do a quick test and verify if things are sane for you if 'CDT' is simply removed from the mapping?
Hey, wait a minute. *I'm* in CDT. Doesn't it just need to be redefined?
Is your CDT == GMT+2? Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
On Wed, 11 Apr 2001, Brian Lloyd wrote:
Could you do a quick test and verify if things are sane for you if 'CDT' is simply removed from the mapping?
Hey, wait a minute. *I'm* in CDT. Doesn't it just need to be redefined?
Is your CDT == GMT+2?
Sorry, I should have been more specific. I'm in Minneapolis/St. Paul, Minnesota. We're GMT-5 here when daylight savings time is in effect. -Tim -- Tim Wilson | Visit Sibley online: | Check out: Henry Sibley HS | http://www.isd197.k12.mn.us/ | http://www.zope.org/ W. St. Paul, MN | | http://slashdot.org/ wilson@visi.com | <dtml-var pithy_quote> | http://linux.com/
Brian Lloyd wrote:
:( The problem is that DT is probably trying to do too much with magical timezone recognition. At some point, some bonehead (and I suspect it probably was me) accepted a request to add CDT to the mapping without noticing that it is a good example of an ambiguous timezone name.
Not a solution, but for part of the history, see http://lists.zope.org/pipermail/zope-dev/1999-April/000323.html where Martijn Pieters writes about a change to DT
Hmm - ok then, (because there is no specific defender of 'CDT' - the mapping was copied from some perl library) I propose to just remove it altogether (in which case the right thing should happen for both cases).
Could you do a quick test and verify if things are sane for you if 'CDT' is simply removed from the mapping?
CDT is not ambiguous at least in the US <g>. I think there was just a mistake made in the map. Didn't Dieter report that the two designations for Central European Time are CET & CEST? -- Tim Cook, President - FreePM,Inc. http://www.FreePM.com Office: (901) 884-4126 ONLINE DEMO: http://www.freepm.org:8080/FreePM
Could you do a quick test and verify if things are sane for you if 'CDT' is simply removed from the mapping?
CDT is not ambiguous at least in the US <g>. I think there was just a mistake made in the map. Didn't Dieter report that the two designations for Central European Time are CET & CEST?
Yes, but I wanted to give fair warning just in case... Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
participants (5)
-
Brian Lloyd -
Dennis Nichols -
Dennis Nichols -
Tim Cook -
Timothy Wilson