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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote:
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?
I'm generally in favor of this, but only if we eggify the *current* DateTime implementation such that people who rely on the incompatible behavior can specify the older version. Note that a lot of the code in DateTime is the constructor DWIM, which datetime completely lacks (in fact, the lack of a string-to-datetime parser in the standard library is a major pain). That DWIM *must* remain in place, even in the new version, as too much application code depends on it. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0Fnl+gerLs4ltQ4RAuW5AJ9JwY+jKGg93WvFmYT1bNrUx+qU1wCgxlwd OdZsF5Q59b92CLrJ3f4xXvc= =NOea -----END PGP SIGNATURE-----
--On 25. August 2007 12:33:41 -0400 Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Andreas Jung wrote:
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?
I'm generally in favor of this, but only if we eggify the *current* DateTime implementation such that people who rely on the incompatible behavior can specify the older version.
Jup, but eggification would likely be the last (and possibly the most easy) step :-)
Note that a lot of the code in DateTime is the constructor DWIM, which datetime completely lacks (in fact, the lack of a string-to-datetime parser in the standard library is a major pain). That DWIM *must* remain in place, even in the new version, as too much application code depends on it.
DWIM? The conversion to datetime happens in my place after calling _parse_args() which is a big pita code...if you mean this...yes, I would _never_ touch it. Andreas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote:
--On 25. August 2007 12:33:41 -0400 Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Andreas Jung wrote:
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? I'm generally in favor of this, but only if we eggify the *current* DateTime implementation such that people who rely on the incompatible behavior can specify the older version.
Jup, but eggification would likely be the last (and possibly the most easy) step :-)
Eggifying the current package shouldn't be hard (it has no dependencies except for zope.interface. In fact, it looks as though Philipp has done it already: http://mail.zope.org/pipermail/checkins/2007-June/010134.html So releasing an egg from there should be straightforward.
Note that a lot of the code in DateTime is the constructor DWIM, which datetime completely lacks (in fact, the lack of a string-to-datetime parser in the standard library is a major pain). That DWIM *must* remain in place, even in the new version, as too much application code depends on it.
DWIM? The conversion to datetime happens in my place after calling _parse_args() which is a big pita code...if you mean this...yes, I would _never_ touch it.
The parsing is what I meant, along with the DWIM related to number of arguments passed to the constructor. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0I9P+gerLs4ltQ4RAjIoAJ42UYkVxnqmjQxIVavDbE33URBoqACfad00 7hoDj7oxRy+KyhdrlxqidIA= =QvY6 -----END PGP SIGNATURE-----
Tres Seaver wrote:
Andreas Jung wrote:
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? I'm generally in favor of this, but only if we eggify the *current* DateTime implementation such that people who rely on the incompatible behavior can specify the older version. Jup, but eggification would likely be the last (and possibly the most easy) step :-)
Eggifying the current package shouldn't be hard (it has no dependencies except for zope.interface. In fact, it looks as though Philipp has done it already:
Yup. Behold: * http://svn.zope.org/DateTime/trunk/ It's currently pulling in the source through an external, but I see no reason why it can't be moved in its own project area. Stuff like DateTime is going to have lots of fixes for already running applications (like timezone fixes, etc.), so having it keep its own release cycle makes sense to me, especially when it's now being evolved towards datetime. The rest of the eggs I created (Acquisition, ExtensionClass, etc.) are mostly independend of the rest of Zope 2 as well and could gain their own projects just as well. Not a full-scale explosion, but just some factoring out... * http://download.zope.org/distribution/DateTime-2.11.0a1.dev-r76287.tar.gz http://download.zope.org/distribution/DateTime-2.11.0a1.dev_r76287-py2.4.egg A ready to go egg of DateTime, completely independent from Zope 2 (only dependencies are zope.interface and zope.testing I believe). -- http://worldcookery.com -- Professional Zope documentation and training
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
--On 26. August 2007 20:00:35 +0200 Dieter Maurer <dieter@handshake.de> 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
On Sun, 26 Aug 2007 11:31:13 -0700, Andreas Jung <lists@zopyx.com> wrote:
I would not care about some incompatibilities if people have the chance using the old version somehow (e.g. through a DT egg).
+1, for what it's worth. ;) Dealing with the existing DateTime implementation has been pain since I started with Zope 2.0.1. I'd be willing to suffer some cleanup and compatibility work if it was fixed once and for all, as would anyone doing anything non-US-centric with dates, I imagine. I don't know about the exact implementation details, but if it's possible to explicitly specify the old DateTime for older installations, that sounds like a great solution. -- Alexander Limi · http://limi.net
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
Dieter Maurer wrote:
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.
I agree with Dieter. I acknowledge Andreas's heroic efforts trying to create a bridge between the two, but I do wonder if it's worth it. As Dieter said, we can't get rid of the cruft for BBB reasons (not only to support old code but old pickles as well!). The only thing we can gain here is a fix for those esoteric timezones bugs. That alone doesn't seem worth a risky operation like that. In my personal opinion, we should * use datetime for all the new stuff that we write, * provide a convenient way to convert DateTime objects into datetime, * create alternate APIs for all the APIs that work with DateTime objects (e.g. create a version of bobobase_modification_time that returns a datetime, same with the CMF DublinCore interface, etc.) * let DateTime rot forever Alexander Limi wrote:
Dealing with the existing DateTime implementation has been pain since I started with Zope 2.0.1. I'd be willing to suffer some cleanup and compatibility work if it was fixed once and for all, as would anyone doing anything non-US-centric with dates, I imagine.
A 'cleaner', much better working version (datetime) and time zone support (pytz) have been around for ever since Python 2.3 was released and supported by Zope 2 several years (!) ago. It was everybody's choice NOT to use it so far. As Andreas has pointed out, converting existing DateTime objects to datetime objects is trivial. In fact, what I've outline above isn't much work (far less than what Andreas would have to do, I would assume) and could've done a long time ago already. Given that you would "be willing to suffer some ... compatibility work" (meaning, adjusting to new APIs that return datetime instead of DateTime objects or adjusting your code to convert DateTimes to datetimes), this sounds like solution that you' should be happy with, too. -- http://worldcookery.com -- Professional Zope documentation and training
Philipp von Weitershausen wrote at 2007-8-27 22:11 +0200:
... In my personal opinion, we should
* use datetime for all the new stuff that we write,
* provide a convenient way to convert DateTime objects into datetime,
* create alternate APIs for all the APIs that work with DateTime objects (e.g. create a version of bobobase_modification_time that returns a datetime, same with the CMF DublinCore interface, etc.)
* let DateTime rot forever
+1. And, the new version of "bobobase_modification_time" should have a more senseful name.
... A 'cleaner', much better working version (datetime) and time zone support (pytz) have been around for ever since Python 2.3 was released and supported by Zope 2 several years (!) ago. It was everybody's choice NOT to use it so far.
Not sure whether "everybody's choice" is correct. I believe that "datetime" is not even importable in TTW code and "datetime" objects not accessible in TTW code -- at least, they have not been until recently... -- Dieter
On 27 Aug 2007, at 22:25 , Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2007-8-27 22:11 +0200:
... In my personal opinion, we should
* use datetime for all the new stuff that we write,
* provide a convenient way to convert DateTime objects into datetime,
* create alternate APIs for all the APIs that work with DateTime objects (e.g. create a version of bobobase_modification_time that returns a datetime, same with the CMF DublinCore interface, etc.)
* let DateTime rot forever
+1.
And, the new version of "bobobase_modification_time" should have a more senseful name.
Absolutely.
... A 'cleaner', much better working version (datetime) and time zone support (pytz) have been around for ever since Python 2.3 was released and supported by Zope 2 several years (!) ago. It was everybody's choice NOT to use it so far.
Not sure whether "everybody's choice" is correct.
I believe that "datetime" is not even importable in TTW code and "datetime" objects not accessible in TTW code -- at least, they have not been until recently...
allow_module('datetime') is all you had to do. Ok, admittedly, pure- TTW developers who can't or won't touch filesystem code were out of luck, but everybody who *knew* about datetime and wanted to use it could have done so.
Philipp von Weitershausen wrote: <snip />
I believe that "datetime" is not even importable in TTW code and "datetime" objects not accessible in TTW code -- at least, they have not been until recently...
allow_module('datetime') is all you had to do. Ok, admittedly, pure-TTW developers who can't or won't touch filesystem code were out of luck, but everybody who *knew* about datetime and wanted to use it could have done so.
There are a lot of pure TTW developers, they don't tend to be vocal on these lists though. It would be really good to get the datetime module allowed for them, along with set and frozenset which are now built in. Laurence
--On 28. August 2007 12:04:35 +0100 Laurence Rowe <l@lrowe.co.uk> wrote:
Philipp von Weitershausen wrote: <snip />
I believe that "datetime" is not even importable in TTW code and "datetime" objects not accessible in TTW code -- at least, they have not been until recently...
allow_module('datetime') is all you had to do. Ok, admittedly, pure-TTW developers who can't or won't touch filesystem code were out of luck, but everybody who *knew* about datetime and wanted to use it could have done so.
There are a lot of pure TTW developers, they don't tend to be vocal on these lists though. It would be really good to get the datetime module allowed for them, along with set and frozenset which are now built in.
I am not sure if TTW developers would be happy with the pure datetime API. datetime basically exposes one useful method for TTW developers: strftime(). DateTime has a much richer API for doing useful things, less useful things and stupid things. I came across python-dateutil some days ago <http://labix.org/python-dateutil> which appears really impressive to me (and useful). python-dateutil + datetime would be an equivalent replacement for DateTime. Just for the logs: I gave up my work on an inplace DateTime migration.. too compliated, too much cruft would have to remain for backward compatibility. Let's see how we can address the issue in a reasonable way :-) Andreas
Andreas Jung wrote at 2007-9-1 12:59 +0200:
... I came across python-dateutil some days ago
<http://labix.org/python-dateutil>
which appears really impressive to me (and useful). python-dateutil + datetime would be an equivalent replacement for DateTime.
Just for the logs: I gave up my work on an inplace DateTime migration.. too compliated, too much cruft would have to remain for backward compatibility. Let's see how we can address the issue in a reasonable way :-)
How about making "python-dateutil + datetime" officially available in Zope? -- Dieter
Andreas Jung wrote: <snip />
Just for the logs: I gave up my work on an inplace DateTime migration.. too compliated, too much cruft would have to remain for backward compatibility. Let's see how we can address the issue in a reasonable way :-)
To enable an evolutionary approach DateTime <-> datetime conversions must be made round-tripable. This is currently difficult as DateTimes have a resolution of milliseconds and datetimes a resolution of microseconds. I propose: * Increase the resolution of DateTimes to microseconds * Modify the DateTime constructor to handle datetime objects * add an asdatetime method which will return a datetime object (avoiding any issues with floating point conversions). If there is support for this I will supply a patch. Laurence
--On 26. September 2007 11:08:23 +0100 Laurence Rowe <l@lrowe.co.uk> wrote:
Andreas Jung wrote: <snip />
Just for the logs: I gave up my work on an inplace DateTime migration.. too compliated, too much cruft would have to remain for backward compatibility. Let's see how we can address the issue in a reasonable way :-)
To enable an evolutionary approach DateTime <-> datetime conversions must be made round-tripable. This is currently difficult as DateTimes have a resolution of milliseconds and datetimes a resolution of microseconds. I propose:
* Increase the resolution of DateTimes to microseconds
* Modify the DateTime constructor to handle datetime objects
* add an asdatetime method which will return a datetime object (avoiding any issues with floating point conversions).
The migration project is dead (for me)..too complex in order to do it right. -aj
Laurence Rowe wrote at 2007-9-26 11:08 +0100:
... To enable an evolutionary approach DateTime <-> datetime conversions must be made round-tripable. This is currently difficult as DateTimes have a resolution of milliseconds and datetimes a resolution of microseconds. I propose:
* Increase the resolution of DateTimes to microseconds
* Modify the DateTime constructor to handle datetime objects
* add an asdatetime method which will return a datetime object (avoiding any issues with floating point conversions).
If there is support for this I will supply a patch.
Sounds as a good first step. Why do you need a microsecond resolution? -- Dieter
Previously Dieter Maurer wrote:
Laurence Rowe wrote at 2007-9-26 11:08 +0100:
... To enable an evolutionary approach DateTime <-> datetime conversions must be made round-tripable. This is currently difficult as DateTimes have a resolution of milliseconds and datetimes a resolution of microseconds. I propose:
* Increase the resolution of DateTimes to microseconds
* Modify the DateTime constructor to handle datetime objects
* add an asdatetime method which will return a datetime object (avoiding any issues with floating point conversions).
If there is support for this I will supply a patch.
Sounds as a good first step.
Why do you need a microsecond resolution?
Performance benchmarks, small timeouts. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Dieter Maurer wrote:
Laurence Rowe wrote at 2007-9-26 11:08 +0100:
... To enable an evolutionary approach DateTime <-> datetime conversions must be made round-tripable. This is currently difficult as DateTimes have a resolution of milliseconds and datetimes a resolution of microseconds. I propose:
* Increase the resolution of DateTimes to microseconds
* Modify the DateTime constructor to handle datetime objects
* add an asdatetime method which will return a datetime object (avoiding any issues with floating point conversions).
If there is support for this I will supply a patch.
Sounds as a good first step.
Why do you need a microsecond resolution?
Only because datetime.datetime has a microsecond resolution. Lossless roundtriping is important so formlib etc can detect changes (DCWorkflow expects DateTime.DateTime, sqlalchemy / zope.schema uses datetime.datetime and I want to use both.) Laurence
Philipp von Weitershausen wrote at 2007-8-27 22:33 +0200:
...
I believe that "datetime" is not even importable in TTW code and "datetime" objects not accessible in TTW code -- at least, they have not been until recently...
allow_module('datetime') is all you had to do. Ok, admittedly, pure- TTW developers who can't or won't touch filesystem code were out of luck, but everybody who *knew* about datetime and wanted to use it could have done so.
Is not an "allow_type" (or several) necessary as well? -- Dieter
On 28 Aug 2007, at 21:48 , Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2007-8-27 22:33 +0200:
...
I believe that "datetime" is not even importable in TTW code and "datetime" objects not accessible in TTW code -- at least, they have not been until recently...
allow_module('datetime') is all you had to do. Ok, admittedly, pure- TTW developers who can't or won't touch filesystem code were out of luck, but everybody who *knew* about datetime and wanted to use it could have done so.
Is not an "allow_type" (or several) necessary as well?
Possibly. I woudln't know. My point was just that it's doable and has been for a long time already.
Philipp von Weitershausen wrote at 2007-8-28 21:49 +0200:
On 28 Aug 2007, at 21:48 , Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2007-8-27 22:33 +0200: ... "datetime" use ... My point was just that it's doable and has been for a long time already.
Yes, it is possible (for a long time) -- but far from being well supported... Maybe, we ensure in the core that the modules "datetime" and "pytz" can be imported and the corresponding instances accessed in TTW code. And as someone else mentioned: "set" and "frozenset" are as safe as "dict". Thus, they, too, could be made available (if necessary with a "safe" wrapper, should "dict" have one). -- Dieter
On 8/25/07, Andreas Jung <lists@zopyx.com> 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
--------------------------------------------------
On 8/25/07, Andreas Jung <lists@zopyx.com> 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.
On 9/14/07, Sidnei da Silva <sidnei@enfoldsystems.com> 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...
participants (9)
-
Alexander Limi -
Andreas Jung -
Dieter Maurer -
Laurence Rowe -
Lennart Regebro -
Philipp von Weitershausen -
Sidnei da Silva -
Tres Seaver -
Wichert Akkerman