[Zope-Coders] test failures in DateTime
Shane Hathaway
shane@zope.com
Thu, 04 Oct 2001 11:14:45 -0400
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