[Zope-Coders] test failures in DateTime

[Shane Hathaway]

Casey Duncan wrote:

> On Thursday 27 September 2001 10:19 pm, Stephan Richter allegedly wrote:
> 
>>At 08:52 PM 9/27/2001 -0400, Andreas Jung wrote:
>>
>>>It seems nobody wants to own DateTime :-)
>>>I tried to solve these problems some time ago but I could not find
>>>the bug. FYI I wrote a fishboal proposal some time ago together with
>>>Stephan Richter with the goal to replace Zope DateTime module with
>>>mxDateTime.
>>>
>>I agree with Andreas (well, I should, shouldn;t I? :-) )! We should make an
>>effort to move to mxDateTime. The advantages are very obvious and there is
>>really no good reason not to do it. In fact, in a couple of days I would
>>have had proposed that in anyway on this list. ;-)
> 
> This might be better posed on zope-dev (and we can move it there if so), but 
> is the license of mxDateTime compatible with the ZPL? It has a kind of funky 
> custom license.

This used to be a concern but not anymore.  It now uses the "wide-open" 
license.

BTW let me say it one more time: there are several ways that DateTime 
*seems* buggy where it actually *isn't*, simply because it deals with 
time zones.  For example, DateTime("2001/09/28 EST") - 
DateTime("2001/09/27 MST") is 0.916666..., or 22 hours.  The problem is 
that that's not the calculation you really want.  The problem with 
DateTime isn't the presence of bugs but the absence of the correct features.

The test suite tests most of the ways that DateTimes are used in Zope 
and then some, so I'm very much in favor of switching to an 
mxDateTime-based implementation if you can get the test suite to pass!

Shane