(Sending reply to the list, since Gustavo doesn't seem to be subscribed.) On 9/17/07, Gustavo Niemeyer <[EMAIL PROTECTED]> wrote: > > Hey Lennart, > > > 1. Giving the timezone string 'GMT+3' meant that you got the timezone > > GMT-3 back. This was done intentionally and I had some discussion with > > Gustavo about that. > > True.. after these discussions I'm sure that the current implementation > isn't ideal. I'll try to fix that in the next dateutil release. > > > > 2. "Timezones in the form of EST5EDT or US/Eastern doesn't work. > > > > Both these can be avoided by keeping the old time and timezone > > interpretation around. > > I'm not aware about that. In fact, I'm curious about what the problem > is. EST5EDT may be seen in the test suite several times, using different > sources of information even. > > >>> tz.gettz("EST5EDT") > tzfile('/usr/share/zoneinfo/EST5EDT') > > >>> tz.tzstr("EST5EDT") > tzstr('EST5EDT') > > > > The third one is the the modules concept of local timezone is set when > > the module is imported, and there was no way to change it afterwards, > > dateutil can get timezones from several different sources and formats. > tzlocal is based on what libc exposes, and I don't advice it to be used > if any better source of information is available. If the fact that > some of its data is initialized as module import time is bothering you, > I can definitely change it, but please keep in mind that there are other > gotchas (variables in the time module won't change unless you call tzset, > for instance) > > I recomment using tz.gettz() instead, which doesn't suffer from any of > the problems you described, and provides much better information > about the local timezone. > > > > in effect making any testing impossible, as any tests in converting > > timezones will only work in the timezone of the one who wrote the > > tests. That's a huge problem when you need to test that timezones work > > properly, and IMO opinion makes the module pretty much useless for any > > Making testing impossible is a bit overstated, IMO. I use TDD in a > daily basis, and testing that environment seems far from challenging. > Time-related logic is tricky to test sometimes, of course, but saying > that dateutil is useless because tzlocal is initialized at import time > is funny, at least. > > Here is a hot-fix for tzlocal, if that's the problem you're blocked on. > > class tzlocal(dateutil.tz.tzlocal): > > @property > def _std_offset(self): > return datetime.timedelta(seconds=-time.timezone) > > @property > def _dst_offset(self): > if time.daylight: > return datetime.timedelta(seconds=-time.altzone) > else: > return self._std_offset > > dateutil.tz.tzlocal = tzlocal > > > -- > Gustavo Niemeyer > http://niemeyer.net >
-- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )