pep proposal : A date object for the standard library

[Kragen Sitaker]

s.keim at laposte.net (sebastien) writes:
> In standard python, dates are defined with two formats:
>  * os module use the POSIX format (elapsed time in seconds since the
> 1970-01-01)
>  * a tupple is defined in the time module
> They are low level format, not really user-friendly.

I sort of agree, but I tend to think that the tuple would be OK if it
was an object with named attributes instead of just being a tuple.

The POSIX format (in floating point) has the additional problem that
it loses precision as we get far from 1970.

Perhaps you could include code samples demonstrating how your proposed
module would make user code simpler?

> What exist today for Python
> 		
> A powerful mxDateTime tools already exist but this package is probably
> to complex to go on the standard distribution[3].
> 
> NormalDate define also a light date class[2].

Can you outline what these packages provide?

> This intermediate format could be defined as a floating point
> representing the modified juian day numbers[5].
> This will be called MJD (Modified Julian Day) in the next part of the
> document.
> 
> In this format, the integer part correspond to the number of elapsed
> days since the start of the day 1858-11-17 CE. Negatives numbers are
> allowed for date before 1858-11-17. The decimal component is the
> fraction of the day corresponding to hour minutes and seconds,
> expressed in GMT.

It might be useful to express the time in TAI rather than GMT,
although that distinction ceases to be meaningful outside of modern
times.

I don't know if this is a substantive objection or not, but this will
lose precision as we move further from 1858. IEEE-754's 64-bit format
has 52 bits of mantissa, or about 15 or 16 decimal digits; by my
possibly-flawed calculations, that means we can express nanoseconds
for about a month or two on either side of the epoch, microseconds for
about 90 years on either side of the epoch, milliseconds for about
90,000 years on either side of the epoch, and seconds for about 90
million years on either side of the epoch.  I'm not sure what not
being able to calculate Jurassic times in milliseconds costs us, but I
thought I should mention it.

Given that Python has arbitrary-precision integers, it might be best
to just use them.

> 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.
> About once every year or two there is an extra second, called a "leap
> second" added as the last second of the December 31 or June 30. For
> example, the last minute of the year 1995 was 61 seconds long, thanks
> to an added leap second. In MJD format, this seconds won't accumulate
> for years to years.

This is why using TAI is a good idea.

Note that this means you can't use your date module to calculate time
intervals easily; in the POSIX format, you can say, "What time is one
hour later than 1995-12-31 23:30:00 UTC?" by adding 3600 to the number of
seconds and get the correct answer, which is 1996-01-01 00:29:59.

> Properties are new in python 2.2, they allow us to assign assessors
> methods to an attribute.

They can be emulated in older Python versions with __getattr__ and
__setattr__.

> That mean that: 
>     - x.day = value will call something like  x.set_day(value)
>     - value = x.day will call value = x.get_day()

This is a wonderful idea.