https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #28 from Jonathan M Davis <jmdavisp...@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). --