Re: Fwd: [Zope-dev] Options replacing DateTime with datetime!?
On 9/17/07, Gustavo Niemeyer <gustavo@niemeyer.net> 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
Hey again Lennart,
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?
Maybe. If there's a problem with parsing, I'll be happy to fix that.
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.
Just use the POSIX-defined TZ variable, and the gettz() method to retrieve the timezone.
from dateutil.tz import gettz
os.environ["TZ"] = "Brazil/East" gettz() tzfile('/usr/share/zoneinfo/Brazil/East')
os.environ["TZ"] = "US/Eastern" gettz() tzfile('/usr/share/zoneinfo/US/Eastern')
(...)
But it makes it impossible without actually modifying the modules code somehow, and in my book, it is reasonable to call that impossible.
Just use gettz(), as explained above. You'll get a richer source of information for free.
Of course nothing is impossible in computing. (...) If I monkey-patch the module for testing, then am I really testing what goes on in production?
These are interesting statements. I won't move into discussing them because it won't benefit the main point. If you'd enjoy some general conceptual discussion we can do so privately. -- Gustavo Niemeyer http://niemeyer.net
participants (2)
-
Gustavo Niemeyer -
Lennart Regebro