[Issue 6725] core.time.dur should accept floating point

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6725

--- Comment #23 from Jonathan M Davis <jmdavisProg at gmx.com> ---
(In reply to Steven Schveighoffer from comment #22)
> (In reply to Jonathan M Davis from comment #16)
> > Durations aren't as bad as timestamps, but it's still asking for
> > trouble.
> 
> This begs the question, what trouble? While I have experienced and seen
> issues with floating point, it has never been when checking if a timer has
> expired or figuring out how long to sleep for. Can you state some examples?

In video-related code that I've had to deal with, we frequently need times to
be exact (e.g. comparing a seek time against the start and end time of a clip).
Using floating point values for that is an incredibly bad idea - one, because
if you're foolish enough to compare for equality, then you're obviously going
to have problems, and two, because the rounding error can make it so that one
timestamp is now after another timestamp when it was supposed to be the same or
slightly before (or the other way around, if you're looking at the beginning of
a clip). The result is that if you use floating point values for timestamps
like that, you very easily end up with floating point-related bugs.

Also, when attempting things like synchronizing multiple video streams, you're
doing duration calculations to figure out what the timestamp is supposed to be,
so if either the duration or the timestamp is a floating point value, then
error is going to creep in. It's really not that uncommon in my experience to
have to calculate timestamps or durations where those calculations will build
up errors if floating point values are used.

Granted, I've worked in a fairly narrow field for a while now, so my experience
may be different from other folks, but if you're doing anything related to
timestamps or timing, using floating point values will result in bugs. And far
too many folks I've worked with don't seem to realize that it's an issue, so
they do it anyway. So, having it be harder to use floating point values with
core.time is _good_ thing in my opinion.

--