Re: Fwd: [Zope-dev] Options replacing DateTime with datetime!?
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
___
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 )
Re: Fwd: [Zope-dev] Options replacing DateTime with datetime!?
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 )
Re: Fwd: [Zope-dev] Options replacing DateTime with datetime!?
(Sending reply to the list, since Gustavo doesn't seem to be subscribed.)
On 9/17/07, Gustavo Niemeyer <[EMAIL PROTECTED]> 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 Systemshttp://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
___
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 )
Re: [Zope-dev] Options replacing DateTime with datetime!?
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 )
Re: [Zope-dev] Options replacing DateTime with datetime!?
-- On 8/25/07, Andreas Jung <[EMAIL PROTECTED]> wrote: Before digging deeper I would like to hear some opinions if this seems a reasonable approach? Unlikely that we can achieve 100% backward compatibility but possibly 99%thoughts...comments? 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? Creating a 'datetime' without timezone information? Why the timezone you are in matters for testing? If you could explain what the problem is, we could ask Gustavo to take a look at the issue. He's very receptive with patches and bugfixes. -- Sidnei da Silva Enfold Systems, Inc. ___ 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 )
Re: [Zope-dev] Options replacing DateTime with datetime!?
On 8/25/07, Andreas Jung <[EMAIL PROTECTED]> wrote: > Before digging deeper I would like to hear some opinions if this seems a > reasonable approach? Unlikely that we can achieve 100% backward > compatibility but possibly 99%thoughts...comments? 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. Unfortunately, I then deleted the directory I did the work in by mistake, and I haven't had the energy to try again later. :-) But yes, I think it's doable, and more, I think it's a good idea. DateTime is too cruddy and hard to maintain, and most likely still full of bugs. -- 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 )
Re: [Zope-dev] Options replacing DateTime with datetime!?
Andreas Jung wrote at 2007-8-26 20:31 +0200: > ... >Conversion between both is pretty much trivial. However I have no idea >how this would solve the DateTime problem. So what are our DateTime >problems? > > - an insane constructor with a parser trying to parse almost every > date format in the world (with lots of guessing and dealing > with ambiguousness) Which you cannot get rid of -- for backward compatibility. > - an insane timezone handling Timezones *are* incredibly difficult. It is not "DateTimes" fault (although there are some bugs, almost surely easily fixable). > - DateTime is doing way too much Which you cannot get rid of -- for backward compatibility. -- Dieter ___ 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 )
Re: [Zope-dev] Options replacing DateTime with datetime!?
--On 26. August 2007 20:00:35 +0200 Dieter Maurer <[EMAIL PROTECTED]> wrote: Andreas Jung wrote at 2007-8-25 17:47 +0200: ... emulate "DateTime" (implicitely) by "datatime" ... Before digging deeper I would like to hear some opinions if this seems a reasonable approach? Unlikely that we can achieve 100% backward compatibility but possibly 99%thoughts...comments? I would prefer a more explicit approach :-) Make Python's "datatime" available in addition to "DateTime" and provide conversion functions between the two. Conversion between both is pretty much trivial. However I have no idea how this would solve the DateTime problem. So what are our DateTime problems? - an insane constructor with a parser trying to parse almost every date format in the world (with lots of guessing and dealing with ambiguousness) - an insane timezone handling - DateTime is doing way too much However after this weekend I have the feeling that this is an mission-impossible project. The lots of problems related to "DateTime" show that date handling is difficult. These difficulties make it not unlikely that the proposed emulation will have difficulties, too. I would not care about some incompatibilities if people have the chance using the old version somehow (e.g. through a DT egg). -aj pgpxmWtve8HJu.pgp Description: PGP signature ___ 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 )
Re: [Zope-dev] Options replacing DateTime with datetime!?
Andreas Jung wrote at 2007-8-25 17:47 +0200: > ... emulate "DateTime" (implicitely) by "datatime" ... >Before digging deeper I would like to hear some opinions if this seems a >reasonable approach? Unlikely that we can achieve 100% backward >compatibility but possibly 99%thoughts...comments? I would prefer a more explicit approach :-) Make Python's "datatime" available in addition to "DateTime" and provide conversion functions between the two. The lots of problems related to "DateTime" show that date handling is difficult. These difficulties make it not unlikely that the proposed emulation will have difficulties, too. -- Dieter ___ 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 )
[Zope-dev] Options replacing DateTime with datetime!?
Hi, perhaps the sun burned too long on my brain today but I investigated some options for replacing DateTime with Python's datetime module. Zope 3 uses datetime and we all know that the DateTime implementation sucks. Especially the timezone implementation has a bunch of problems (count the bugtracker issues related to timezone errors). Constraints: We can not get rid of the DateTime class and its API for backward compatibility reasons. Idea: The DateTime class remains in place and uses an instance attribute to represent the original value of a DateTime object as instance of datetime. Calls to the old DateTime API are proxied to corresponding calls of the datetime API (or emulated) Efforts so far: I have some quick-and-dirty implementation that can construct the datetime instance directly within the DateTime constructor and when loading an object from the ZODB (using a custom __setstate__() implementation...could be used for an on-the-fly migration). This seems to work properly. For timezone related issues I am using pytz. However there is a problem with using pytz: the timezone names supported by pytz are sometimes different from the standard one. E.g. 'GMT+0400' is represented in pytz as '/Etc/GMT+0400'...however that seems to be solvable. Before digging deeper I would like to hear some opinions if this seems a reasonable approach? Unlikely that we can achieve 100% backward compatibility but possibly 99%thoughts...comments? Tnx, Andreas pgpztiAiCXQb1.pgp Description: PGP signature ___ 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 )
