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")
> >>> tz.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
Lennart Regebro: Zope and Plone consulting.
+33 661 58 14 64
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -