[Issue 11353] core.time.Duration is missing to() conversion function

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Oct 25 16:58:57 PDT 2013


http://d.puremagic.com/issues/show_bug.cgi?id=11353


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg at gmx.com


--- Comment #3 from Jonathan M Davis <jmdavisProg at gmx.com> 2013-10-25 16:58:55 PDT ---
Floating point time is an abomination (as has been discussed when floating
point durations have come up before), and TickDuration really shouldn't have
it, but unfortunately, I more or less kept Shoo's design when I integrated into
the std.datetime stuff. If I could go back, I would remove TickDuration
entirely and just use Duration for all durations (possibly adding a type that
was used only for the monotonic time), since it's unlikely that the system
clock would have precision greater than a hecto-nanosecond, and the extra
complication of two duration types isn't worth it IMHO.

So, I'm very much against migrating any of TickDuration's floating point
features over to Duration. I'd deprecate TickDuration, but at this point, it
would probably break too much code to be acceptable. I should probably make it
so that TickDuration aliases to Duration and then try and strip TickDuration
out of as much of core.time and std.datetime as possible. Then maybe we could
move towards deprecating it. It's definitely one of the sore points in the time
stuff IMHO, and a lot of stems from the fact that it wasn't really designed
with the rest but sort of shoehorned in.

> Apparently I have to use:
> Clock.currTime.fracSec.msecs

Yeah, the fractional seconds are handled separately, because they don't divide
out like the other units do. You can break up SysTime into year, month, day,
hour, minute, and second, but it doesn't make as much sense to break out msecs,
usecs, and hnsecs. Those units are really just differing levels of precision of
the same thing rather than different parts of the whole like the other units
are. And in particular, I wouldn't expect you to want to separate the msecs,
usecs, and hnsecs out like is typical with the large units - e.g. if separated
like the larger units, 12,245,327 hnsecs would become 122 msecs, 453 usecs, and
27 hnsecs whereas I would think that you'd want 122 msecs, 122,453 usecs, and
12,245,237 hnsecs (which is what you get now by treating them as fractional
seconds which you convert to one of the 3 units). Unfortunately, the resulting
API is a little unwieldy, but it's the best that I could come up with, and I
don't remember any major objections to it when it was reviewed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list