pep proposal : A date object for the standard library

Chris Barker chrishbarker at attbi.com
Fri Dec 7 18:23:25 EST 2001


Harald Hanche-Olsen wrote:

> There are some problems with using a seconds count as the basis for
> calendrical calculations.  A big one is that nobody knows when leap
> seconds will happen in the future.  So you might schedule an event for
> the time 2038-01-19 03:14:08 UTC, but you cannot know how many seconds
> that is from now, 

That sounds to me like a really good reason why we don't have to worry
about femtoseconds. Resolving time down to units that small is simply
incompatable with calender dates.

> I think that keeping calendrical calculations and time issues strictly
> separate is a good idea myself.  I would even go so far as to suggest
> a completely separate module just for dates and calendars.
> advantage is that you can deal with that without even getting into the
> mess of leap seconds, time zones and daylight saving time.
> Leave that for another module.

I disagree. A Date module that doesn't even understand hours would have
pretty limited usefulness.

> An advantage of this scheme is that a date module
> has at least a chance of becoming simple enough to become a part of
> python.  I will make no such assertions about time.

It has to be both simple and useful. I think it would fail the useful
test. A DateTime module that doesn't resolve any finer than seconds
would be very usefull, and I think doable. With all this leap-second
stuff, resolving finer than that just isn't worth it.

I really would like to see SOMETHING get into the standard library,
however. The current time module is far too limiting.

-Chris



-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------



More information about the Python-list mailing list