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