mxTools (was Re: why no "do : until"?)

[Alex Martelli]

"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
news:LRFzDVA+eFX6Ew4t at jessikat.fsnet.co.uk...
    [snip]
> I point out that there are several competing binary time formats

Sure, but that doesn't matter as much as the interface time/date
objects present on the _Python_ side of things.  Binary formats
internally used differ hugely between databases, too, but, who
cares?  Only the author of the DB-interface module -- they'll have
to handle the conversion; but, on the Python side of things, the
object can again behave uniformly.

> including the fairly ludicrous M$/Lotus 1900 is a leap year one. None of
> the 64bit ones has a hope of surviving too long in a world where
> nano/pico seconds are becoming important.

I suspect that the format limitations of widespread databases will
keep time-formats of 64 bits or fewer around for a long time; one
rarely needs picosecond-accuracy on the _same_ time objects that
need to encode dates across many millennia.

When one _does_ have such a need, the mxDateTime internal format
requires usage of _two_ objects -- a DateTime object for the
integral-second, and a RelativeDateTime one for the fraction
of a second.  If picosecond (10**-12) accuracy is required, the
typical 53-bits precision of a 'double' (internally used for
RelativeDateTime) has a few bits left over that can be used for
an integer-part, but not one of up to a full day (just a few
hours' worth).  Never having worked with over-nanosecond accuracy
myself, I'm more used to having bits to spare (keeping a date's
midnight in the absolute part, all the rest in the relative one;
I wasn't doing it in Python, though, but rather in a homebrewn
C struct).


Alex