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

[via Digitalmars-d-bugs]

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

--- Comment #27 from Steven Schveighoffer <schveiguy at 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.

--