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