pep proposal : A date object for the standard library

[sebastien]

Thanks for your responses

Here my feeling about theim. I'll try to include your comment's in a
second draft of the PEP, but there is no chance that this will be done
before Monday.

RB> = Robin Becker
KS> = Kragen Sitaker 
CB> = Chris Barker
OB> = Oleg Broytmann 
PH> = Phil Hunt
GE> = Greg Erwin
------------

CB>I use mxDateTime frequently, and it is a fabulous package. (...) 
CB>It makes a whole lot more sense to me to put in a trimmed-down
CB>version that to re-invent this particular wheel.
OB>Just a day ago the question was raised (by me) in zope list. The
answer
OB>was: both Guido and Marc-Andre said "no". It is a matter of
support. Who
OB>will support the module in the std python lib?
I love mxDateTime too.
My first idea was to write a post with "WE MUST HAVE mxDateTime IN THE
STANDARD LIBRARY"
But, when I restarted my brain, it happened to me that mxDateTime
exist since a quite
long time, and then if it is not now in the standard library, it's
probably for good
reasons. I didn't saw other reasons than support costs, cool I was
true!

KS>Note that this means you can't use your date module to calculate
time
KS>intervals easily.
My feeling was that this elapsed day format should only be used for
calendar
class interoperability. The end user should use the arithmetic methods
provided
by calendar classes and he shouldn't have to bother with this format.
For sample he should be able to write something like:
elapsed_time = FrenchRevolutionCalendar(3,VENDEMIAIRE,15) -
date(1789,7,14)

RB>It seems odd to define dates as a duration in days from a fixed
time and
RB>then define durations in a different scale ie seconds. 
My intuitive feeling was that seconds are more natural for expressing
duration,
both in Python and in current life (second is the SI unit).
And if we hide the elapsed day format to calendar classes users, the
two
scales doesn't seem so odd for me.

KS>I sort of agree, but I tend to think that the tuple would be OK if
it
KS>was an object with named attributes instead of just being a tuple.
Not a real objection, but I feel a little better to write x.day
instead of x[2].

KS>The POSIX format (in floating point) has the additional problem
that
KS>it loses precision as we get far from 1970.
In fact the format I suggested for calendars interoperability has the
same problem :(

KS>that means we can express nanoseconds
KS>for about a month or two on either side of the epoch, microseconds
for
KS>about 90 years on either side of the epoch, milliseconds for about
KS>90,000 years on either side of the epoch, and seconds for about 90
KS>million years on either side of the epoch.  I'm not sure what not
KS>being able to calculate Jurassic times in milliseconds costs us,
but I
KS>thought I should mention it.
Thank's for your precisions, I'll add this to the PEP

>>In this format, the integer part correspond to the number of elapsed
>>days since the start of the day 1858-11-17 CE. 
PH>Any reason why that day particularly?
It's something like 2400000 days after the conjonction of 3 specific
astronomical
events (see the link [4] of the PEP). Given the previous results, it
would be better
to choose an epoch nearer current dates (maybe the 2000/1/1 or Guido
soon birthday ;-))

RB>wouldn't it be wise to establish the representation limits in years
and
RB>fractions of a second and make these a required part of
implementations
RB>of AbstractDate derived classes.
Do you mean to add methods like:
- max_year()
- min_year()
- precision()
That seems a good idea to me, I'll add this, with an exception that
should be
raised when a date is outside the calendar class range.

CB>I would argue that applications that deal with nanoseconds are of a
CB>different breed than those that deal with day, month, year type
calculations.
CB>There is no need for a single package to handle both well.
I agree with that, maybe I should add this to the PEP. My feeling is
that the 80% case
won't bother with times shorter than what a computer clock can return.

PH>Perhpas it'd be better to have se seconds as a separate integer,
for
PH>accuracy of arithmetic.
KS>Given that Python has arbitrary-precision integers, it might be
best
KS>to just use them.
I think that 1 millisecond for 90.000 years is a quite good result.
In fact, the better argument against real number is arithmetic
problems, I hope we can
solve theim by saying that all numbers between x and x+precision are
equals.
If we can't, then your solution is probably the best, but:
- this will make calculs a little more complex
- we must choose the scale for the time number (seconds seems a little
restrictive to me)

KS>It might be useful to express the time in TAI rather than GMT,
KS>although that distinction ceases to be meaningful outside of modern
KS>times.
Could you give me more explanations? I suppose that what is called GMT
in
computer litteracy is in fact TAI.

KS>Perhaps you could include code samples demonstrating how your
proposed
KS>module would make user code simpler?
I'll try to do that for next draft of the PEP ;-)

>> What exist today for Python
>>powerful mxDateTime tools already exist 
>> NormalDate define also a light date class[2].
KS>Can you outline what these packages provide?
Yes this chapter of the PEP need a bit of explainations. I'll do that.
 
>> I feel this solution better than the POSIX convention to count the
>> elapsed time in seconds because not all the days have the same
length.
GE>What?!? This sounds more like an argument for NOT using days as
GE>the basic unit. Otherwise you can't meaningfully take the
difference
GE>between two dates and express it in the same units.
GE>Because of what you said above about leap seconds (...)
I must admit there is something dificult here.
This need more thought, but in the two case you will have problems to
use both
a class which ignore leap seconds and a class able to use theim.
With the day unit you have problems for duration arithmetic, with the
second unit you have problems for convertion betwwen calendards
classes. My feeling is that the second case is most common than the
first. By the way, of course the standard class shouldn't bother with
leap seconds.