(Sending reply to the list, since Gustavo doesn't seem to be subscribed.) On 9/17/07, Gustavo Niemeyer <gustavo@niemeyer.net> 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