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

[via Digitalmars-d-bugs]

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

--- Comment #28 from Jonathan M Davis <jmdavisProg at gmx.com> ---
(In reply to Steven Schveighoffer from comment #24)
> 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.

Yeah. That reduces the problem considerably. Using floating point values for
timestamps or durations is outright wrong IMHO, particularly when any
calculations are done. Simply creating a duration from a floating point value
isn't anywhere near as bad.

But at the same time, it's pretty trivial to just do msecs(1500) instead of
seconds(1.5).And many other libraries which deal with time such as Boost, the
Java SDK, Joda, and Noda don't seem to accept floating points for constructing
durations.

I can definitely see why some folks would want it, but it goes against my every
instinct about dealing with time stuff to allow floating point values. Maybe I
just need to stew on this a bit more to convince myself that this isn't a
horrible idea.

Regardless, if we do it, it needs to add just enough functionality to give the
usability boost that folks like Vladimir are looking for without adding general
capabilities for handling floating point values (e.g. even if it's okay to make
dur and its aliases support floating point values, I wouldn't want convert to,
because that would then support more general floating point time operations).

--