[Zope] insane Central Daylight Time, Zope 2.2.2

[Brian Lloyd]

> >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