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

[via Digitalmars-d-bugs]

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

--- Comment #22 from Steven Schveighoffer <schveiguy at yahoo.com> ---
I think adding the 'best' way to convert a floating point to core.time may be
better than saying 'roll your own, and deal with floating point issues'.

Really, anyone can say: dur!"hnsecs"(val * (1000 * 1000 * 1000 / 100)), and
have a very bad conversion routine. This is not something we want people to do.

I'd rather have them do intervalToDuration(val), and do the best we can to
avoid rounding errors. Once you are in Duration land, calculations are sane.

(yes, I'm suggesting just a single function that only supports interval in
seconds instead of taking over functionality of dur)

(In reply to Jonathan M Davis from comment #16)

> Every application that I've seen use doubles for time has had bugs because
> of it.

I have a completely different experience, especially when the underlying core
library supports it.

> It works in a lot of cases, but you end up with subtle problems as a
> result.

I think this is an exaggeration. It works in nearly all cases, since the least
significant parts of a timestamp are not critical to get correct, and most
timing code does not use equality for comparison.

> 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?

--