[Zope-Coders] test failures in DateTime

[Guido van Rossum]

[me]
> >It's long overdue, but mxDateTime is of such baffling complexity that
> >I'm not sure it belongs in the core.  It just doesn't feel Pythonic to
> >me.

[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.

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?

--Guido van Rossum (home page: http://www.python.org/~guido/)