pep proposal : A date object for the standard library

Chris Barker chrishbarker at attbi.com
Mon Dec 10 19:00:01 CET 2001


Greg Ewing wrote:
> Yes. Once you've solved that problem down to the level
> of seconds, smaller units aren't any harder. So we
> might as well choose a unit smaller than anything
> anyone is likely to need.

OK, if you really have seconds correct, then yes, 10**-whatever seconds
would only be a matter of storage.

But... That means you have to have seconds correct to 10**-whatever. The
leapsecond rule someone posted stated that you waited until you were off
by more that some fraction of a second (.75, .5? I don't remember),
anyway, that means that you will be off by a monsterous amount in terms
of nanoseconds, but by a negligable amount in terms of seconds. Indeed,
if you ignore leap seconds, you can still resolve hundreds of years, and
only be off by a few seconds at most. That would be absolutely fine for
most non-physics applications. I suppose it would be more honest to 
only display minutes (or decaseconds?), so you would be accurate to the
sigfigs you presented. Think of this as a significant figure issue. If
you wanted to know how many seconds it was since Jan 23th, 1856, you
would get a whole lot of significant figures, even if the last digit was
wrong. (and only the last one would be wrong)

Any of these would be fine with me, and, I think, I whole lot more
useful than just dates.

Trying to resolve particle physics level time and dates in  the same
package would be a whole lot more work (if even possible), and have
limited usefullness. When I do any kin dof time series analysis, I
convert everything to units if delta-t from the start of the record (or
something like that) anyway, that way I can use standard FFT and other
routines. Anything that relied on a Python DateTime module would have to
do all the analysis in Python, and be dreadfully slow.

Would any of you actually use a DateTime module for an application that
would require incredably small resolution??

By the way, the only technical objection I have heard to the mxDateTime
module is that it take 32 bytes (or maybe more) per DateTime object. Is
this a problem for the kind of applications you all forsee using such a
package for?

-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