On 9/14/07, Sidnei da Silva <[EMAIL PROTECTED]> wrote:
> --------------------------------------------------
> > Yeah, I had that idea as well, and also tried it and also got stuck on
> > timezones. :-)
> > I used dateutil, though, and one of the main problems with that is
> > that it calculates what timezone you are in when you load the module,
> > which basically makes timezone testing impossible. pytz may be a
> > better choice.
>
> Uhm, I am not quite sure that is the case. What exactly is the problem?

There was three problems. Two was in interpreting timezones:
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.

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.

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,
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
such work. For example, the Calendaring products tests fails unless
you are in your timezone, Sidnei. ;-) I'm pretty sure I mentioned that
at one point...


-------------

I should say that I never explored the option of changing Zope to
never use DateTimes internally, and thereby just switching to datetime
and let DateTime rot. This may indeed be a simpler option...
_______________________________________________
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