Fwd: [Zope-dev] Options replacing DateTime with datetime!?

[Sidnei da Silva]

(Sending reply to the list, since Gustavo doesn't seem to be subscribed.)

On 9/17/07, Gustavo Niemeyer <gustavo at 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