https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #22 from Steven Schveighoffer <schvei...@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? --