On 9/17/07, Gustavo Niemeyer <[EMAIL PROTECTED]> wrote:
> > 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')

OK, I'm just going after my old notes here, and they could be wrong.
It could be that these types of timezones doesn't work in a datetime string?

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

The important part is that there is some sort of way to tell the
module what the local timezone is, so that you can test conversions.

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

Doens't help as long as conversions use a concept of a local timezone
which isn't controllable.

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

Of course nothing is impossible in computing. But it makes it
impossible without actually modifying the modules code somehow, and in
my book, it is reasonable to call that impossible. If I monkey-patch
the module for testing, then am I really testing what goes on in
production?

-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
_______________________________________________
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 )

Reply via email to