(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")
> >>> tz.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):
> def _std_offset(self):
> return datetime.timedelta(seconds=-time.timezone)
> def _dst_offset(self):
> if time.daylight:
> return datetime.timedelta(seconds=-time.altzone)
> return self._std_offset
> dateutil.tz.tzlocal = tzlocal
> Gustavo Niemeyer
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
** No cross posts or HTML encoding! **
(Related lists -