www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11353] New: core.time.Duration is missing to() conversion function

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11353

           Summary: core.time.Duration is missing to() conversion function
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody puremagic.com
        ReportedBy: andrej.mitrovich gmail.com



10:39:40 PDT ---
You can use to!() on a TickDuration but not on a Duration:

-----
import core.time;
import std.stdio;

void main()
{
    auto tickDur = cast(TickDuration)50.msecs;

    // 0.0499997
    writeln(tickDur.to!("seconds", float));

    // Error: no property 'to' for type 'Duration'
    writeln(50.msecs.to!("seconds", float));
}
-----

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 25 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11353




16:00:49 PDT ---
Same thing for SysTime:

stderr.writefln("Current time: %s", Clock.currTime.msecs);

Error: function core.time.dur!"msecs".dur (long length) is not callable using
argument types (SysTime)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 25 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11353




16:03:12 PDT ---


 Same thing for SysTime:
 
 stderr.writefln("Current time: %s", Clock.currTime.msecs);
 
 Error: function core.time.dur!"msecs".dur (long length) is not callable using
 argument types (SysTime)


Apparently I have to use:

Clock.currTime.fracSec.msecs

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 25 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11353


Jonathan M Davis <jmdavisProg gmx.com> changed:

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



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: -------
Oct 25 2013