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

[via Digitalmars-d-bugs]

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

--- Comment #24 from Steven Schveighoffer <schveiguy at yahoo.com> ---
I think those concerns really don't apply here as much as you think. We are
allowing the creation of durations via floating point numbers, not storing
durations as floating point numbers, or doing math with floating point numbers.

(In reply to Jonathan M Davis from comment #23)
> 
> 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.

I think this situation would not arise. Code would still (I hope) be comparing
SysTime's or Durations, not floating point values. One just uses a floating
point value to generate a Duration.

If someone is going to use floating point values to store their main time
stamps, then they are going to invite such problems, and of course the
core.time types don't apply.

Remember, all the math is being done AFTER the conversion to integer-based
Duration.

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

I think the types we have already alleviate the need to work with floating
point directly. Why would they use floating points for this instead of
Duration/SysTime? Using floating point to specify literals, or to easily
convert a user-supplied value to a duration doesn't mean one is going to just
wholesale throw out all conveniences of std.datetime.

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

For all of 2012, and 2013, I worked on a video project based on iOS and Linux,
and on the iOS side, we used NSDateTime and NSTimeInterval, and really didn't
ever have any problems. NSTimeInterval is typedef'd as a double. The experience
level of the developers is probably different than yours, but I do believe
quite a few people successfully use Apple's SDK for timing without issues.

I think we can put appropriate warnings on a function that does the conversion
to allay concerns of abuse. If we make it *possible*, but not quite
*comfortable*, I don't think it's such an issue. I.e. don't allow Duration +=
double, or SysTime + double.

Code like this is possible to get right and is accurate, I think we should
support it to some degree:

auto timeout = Clock.currTime + durationFromInterval(1.2); // timeout in 1.2
seconds

--