[Zope-Coders] test failures in DateTime

[Shane Hathaway]

Guido van Rossum wrote:

> [Stephan Richter]
>>I actually agree with you. BUT, what about making a nice small module for 
>>the "Python end-user" that is working the Pythonic way. Small, simple and 
>>sweet. This way we can hide the complexity (and do not need to change 
>>anything in the mxDateTime module/API) and have build just a small, 
>>Pythonic module on top of it. :-)
>>
> 
> Hm.  That doesn't sound like a very Pythonic approach to me, mostly
> due to the effort needed to understand mxDateTime (its source code is
> HUGE).
> 
> Wouldn't it make more sense to separate this out somehow in two parts?
> 
> Part 1 would provide a space-efficient and easily picklable
> representation for dates and times with a reasonably wide range (from
> 0AD to Y10K) and precision (milliseconds), with some timezone support
> (indicating the offset in minutes from GMT, *or* indicating "local
> time" when no TZ info is available).  I'd also like to see
> representable: dates without times; times without dates; time deltas.
> All this fits (barely) in 64 bits.  Formatting would be limited to the
> formats that the current time module supports (plus a way to extract
> the milliseconds).  Arithmetic would be limited to adding and
> subtracting time deltas.


Hmm, that might be a fun project.  Here's one way to pack the bits:

15 bits   (signed) year (16383 BC to 16383 AD; 0 means 0 BC)
  4 bits   month (0 to 11)
  5 bits   day (0 to 30 or perhaps 1 to 31)
17 bits   second (0 to 86401 including leap seconds)
10 bits   millisecond (0 to 999)
11 bits   (signed) timezone offset in minutes (-720 to 840)
  2 bits   unused

The year set to -16384 would mean no date is set.  The second set to 
131071 would mean no time is set.  Or maybe the two unused bits would be 
flags indicating whether the date and time are set.

Note that the second contains the minute and hour.  In my own experience 
with writing date/time handlers I have found that it's easier to work 
with times this way than it is to work with hours and minutes separately.

> Part 2 would provide tons of alternative formatting options and
> calendrical arithmetic (including Julian and Gregorian calendars etc.)
> and locale-specific formatting.
> 
> What's the advantage of keeping the mxDateTime API?

You'd think somebody would have written a well optimized, small, easily 
understood, open source C-based date/time module by now.  I think we 
were all hoping mxDateTime was it, but apparently it's not since you say 
it's not small and not easily understood.

Shane