pep proposal : A date object for the standard library
Chris Barker
chrishbarker at attbi.com
Mon Dec 10 13:00:01 EST 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