[Zope-Coders] test failures in DateTime

[Tres Seaver]

Tim Peters wrote:

> [Stephan Richter]
> 
>>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.
>>
> 
> How many bytes do each of the alternatives consume?  In my experience, most
> buggy date/time gimmicks are driven by an overwhelming need to conserve
> space.


ROFL.  DateTime.DateTime instances are optimized *entirely* in the other 
direction, to trade space off in favor of rendering speed.  They have
lots of instance attributes:

  _pmhour     int (_hour in 12-hour time)
  _pm         string, 'am' or 'pm'
  _dayoffset  int
  _fmon       string, copy of full name of the month
  _amon       string, copy of short name
  _pmon       string, copy of short name, with '.' if abbreviated
  _fday       string, copy of full name of day
  _aday       string, copy of short name of day
  _pday       string, copy of short name of day with '.' appended
  _nearsec    int (seconds)
  _year       int
  _month      int
  _day        int
  _hour       int
  _minute     int
  _second     int
  time        float (time.time() value)
   _d         float (days since epoch)
   _t         float (fractional part of _d)
  _tz         string (name of timezone)
  _millis     int (milliseconds since midnight)


The bugs in question are truly actually bugs in the test's handling
of floating point rounding, exposed by the changes in rounding between
Python 1.5.2 and Python 2.1.  We should fix the tests, and then carefully
consider Stephan and Andreas' proposal:  one thing to examine is the
relative space/time tradeoffs between mxDateTime and the current
implementation:  the obsession with rendering speed evident in the
current design was based on lots of blood spilt a fair while ago; we
ignore that at our peril.

BTW, DateTime.DateTime instances are (effectively)
immutable, so lots of the nastiness involved in swapping out alternate
implementations should be smoothed away -- any implementation of the
(fat) query interface, which will also support the current construction
semantics, would do.

While we are at it, we should look into aliasing the special rich
comparison operators onto the existing DateTime.DateTime methods:

  greaterThan(self,t)
  greaterThanEqualTo(self,t)
  equalTo(self,t)
  notEqualTo(self,t)
  lessThan(self,t)
  lessThanEqualTo(self,t)

The performance of DT instance comparison in Python 2 would be
enhanced a lot.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com