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

--- Comment #27 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Sobirari Muhomori from comment #25)
> (In reply to Steven Schveighoffer from comment #22)
> > 
> > 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.
> 
> We were unfortunate enough to depend on exact match of timestamps: an electronic signature algorithm dictates that signatures must be certified with a timestamp, so as the timestamp is hashed, it must match to the last bit and in our case it should work reproducibly across the following set of technologies: x86-32, x86-64, arm32, arm64, soft float, hard float, windows, linux, iOS, android, .net, java, obj-c, delphi, c++.

That has nothing to do with allowing specification of durations via floating point. NOBODY is suggesting to replace the representation of a timestamp with a floating point value, just a mechanism to convert a floating point value into a duration (which would be represented, bit-for-bit, exactly the same on all those platforms.


> The examples presented are quite esoteric and don't prove necessity of having floatDur in standard library. Though, floatDur can be included in docs to help people copy it if they really need it.

I agree with Vladimir. Specifying 1.5 or 1.2 seconds to sleep is not esoteric or even uncommon. Depending on exact hashing of timestamps across many different platforms is.

--

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

--- Comment #28 from Jonathan M Davis <jmdavisProg@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).

--

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

Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |---

--- Comment #29 from Jonathan M Davis <jmdavisProg@gmx.com> ---
I'm switching which of the two is marked as a duplicate, because this is the original, all of the discussion is here.

--

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

--- Comment #30 from Jonathan M Davis <jmdavisProg@gmx.com> ---
*** Issue 13176 has been marked as a duplicate of this issue. ***

--

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

--- Comment #31 from Jonathan M Davis <jmdavisProg@gmx.com> ---
Okay. I was going to say that allowing stuff like seconds(.033) would encourage a lack of precision even in cases where precision was required, and I really didn't lie that idea, but it looks like the lack of precision really isn't all that bad. The largest that the error gets is one hnsec:

import std.algorithm;
import std.datetime;
import std.stdio;
import std.string;

void main()
{
    long i = 0;
    immutable units = convert!("seconds", "hnsecs")(1);
    immutable mult = 1.0 / units;
    for(double d = 0; d < 1; d += mult, ++i)
    {
        auto result = cast(long)(d * units);
        assert(result == i || result == i - 1 || result == i + 1,
               format("%s %s %s", i, d, result));
    }
}

So, simply constructing a Duration from a floating point value doesn't introduce much error. I still don't think that it's a good habit to get into, but with Duration and SysTime using long internally, we avoid any major problems.

However, I don't think that we should be making convert work with floating point values like https://github.com/D-Programming-Language/druntime/pull/905 does, because that helps make the problem more general, and we should probably avoid making Duration.total support it unless someone has a really good reason for it, since it would make it easier to manipulate durations as floating point values, and that's not something that I think that we should support.

--

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

Sobirari Muhomori <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #32 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
(In reply to Vladimir Panteleev from comment #26)
> (In reply to Sobirari Muhomori from comment #25)
> > That's an overengineered interface and should be done in your code. Fractions of timeouts are practically indiscernible, nobody would need to specify it that way.
> 
> Huh? That's pretty much the standard way to specify timeouts in many utilities (sleep, timeout, top...). I don't understand your argument - are you saying that no one should ever need to write a shell script that sleeps for less than 1 second?

It's meaningful to sleep for 200ms, but not for 0.2s. When you need a better precision, you switch to the appropriate unit. How would you specify 1/60 fraction of a minute?

> (In reply to Sobirari Muhomori from comment #25)
> > The examples presented are quite esoteric
> 
> IMHO the counter-examples presented here are the esoteric ones. Consider:
> 
> - hashing of time values

Digital signature is an important example. Cryptographic security is an important technology enjoying wide use.

> vs.
> 
> - allowing the user to specify a fractional number of seconds to sleep for

Millisecond exists precisely for that purpose. In my experience millisecond precision works fine up to a scale of a minute (even though you don't need milliseconds for durations >2s).

> - tweaking a literal in your code to sleep for 1.5 seconds instead of 1

It's again a need for a precision better than a second. Though, I'd still question that 1.5s is much better than 1 or 2 seconds.

(In reply to Steven Schveighoffer from comment #27)
> That has nothing to do with allowing specification of durations via floating point.

I replied to the statement that there's no problem with floats in time arithmetic. I'd say, it should be discouraged.

> > The examples presented are quite esoteric and don't prove necessity of having floatDur in standard library. Though, floatDur can be included in docs to help people copy it if they really need it.
> 
> I agree with Vladimir. Specifying 1.5 or 1.2 seconds to sleep is not esoteric or even uncommon. Depending on exact hashing of timestamps across many different platforms is.

The requirement arises from the fact that the signature is generated and checked on client, and clients are diverse in software and hardware. I presented a real range of technologies of our clients. Well, maybe I can withdraw the c++ requirement.

BTW, the resolution was wontfix.

--

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

yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |yebblies@gmail.com
         Resolution|WONTFIX                     |---

--- Comment #33 from yebblies <yebblies@gmail.com> ---
(In reply to Sobirari Muhomori from comment #32)
> 
> BTW, the resolution was wontfix.

Please do not close bugzilla issues that are still being discussed.

--

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

--- Comment #34 from Vladimir Panteleev <thecybershadow@gmail.com> ---
(In reply to Sobirari Muhomori from comment #32)
> It's meaningful to sleep for 200ms, but not for 0.2s. When you need a better precision, you switch to the appropriate unit. How would you specify 1/60 fraction of a minute?

I still don't understand this argument. 200ms and 0.2s are the same thing, how can it be meaningful to sleep for 200ms but not for 0.2s?

> Digital signature is an important example. Cryptographic security is an important technology enjoying wide use.

So are thousands and thousands of other technologies being in use on your computer right now. Anyway, I don't see how this applies anyway, since this particular proposed change does not concern itself with timestamps, or calculations of durations - only conversion.

> Millisecond exists precisely for that purpose. In my experience millisecond precision works fine up to a scale of a minute (even though you don't need milliseconds for durations >2s).

Are you saying that the program should just accept an integer number at the lowest precision it needs? That's just wrong: 1) it puts abstract technical reasoning before user experience; and 2) it strays from a well-established convention.

> It's again a need for a precision better than a second. Though, I'd still question that 1.5s is much better than 1 or 2 seconds.

I don't understand this argument. Are you saying that no program should ever need to sleep for 1.5 seconds?

--

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

--- Comment #35 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to Vladimir Panteleev from comment #34)
> 200ms and 0.2s are the same thing,
> how can it be meaningful to sleep for 200ms but not for 0.2s?

0.2 cannot be represented exactly as a floating point value. Therefore, rounding error starts creeping in if you start adding many 0.2 increments. At the end, the books don't balance.

Roundoff errors must be handled by the user, not the core library, because the core library cannot know what the user is doing with their FP calculations.

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |WONTFIX

--