James Kanze
11/21/2008 9:36:00 AM
On Nov 20, 2:12 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> Lars Uffmann wrote:
> > What's wrong with the (imo really good) VB approach to store
> > dates as a floating point value with the whole numbers being
> > the days since day X and the fraction being the part of the
> > day elapsed?
> Accuracy comes to mind. For example the value 0.1 cannot be
> represented accurately with base-2 floating point numbers (for
> the exact same reason as 1/3 cannot be represented accurately
> with base-10 decimal numbers).
> If you add 0.1 to itself 10 times, you won't get 1.0 (you get
> a value which is extremely close to it, but not exactly 1.0).
> That might not be what one wants.
Just a nit, but you *might* get 1.0. More accurately, too, you
probably can't add 0.1 to itself, because you can't have a value
0.1, just a value which is extremely close to it. Although the
standard allows base 10 floating pointer arithmetic, I don't
know of a modern implementation that uses anything other than
base 2, 8 or 16. And 0.1 isn't representable in any of those
bases. (And of course, if adding 0.1 ten times does happen to
work, just choose some other value---whatever the
representation, adding 1/N to itself N times will fail to give 1
for some N. Because 1/N isn't representable.)
But the basic objection remains: you can't exactly represent
seconds, and the results of any calculations which should result
in seconds may be off by some very small amount. Which could
cause problems if you want to compare two times. Not to mention
that you're likely to end up with fractions of a second when you
don't want them. All in all, using floating point here is
probably the worst possible solution (but the standard allows
it: time_t may be a typedef to double).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34