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


--- Comment #0 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-10-25 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: -------

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



--- Comment #1 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-10-25 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: -------

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



--- Comment #2 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-10-25 16:03:12 PDT ---
(In reply to comment #1)
> 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: -------

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


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

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


--- Comment #3 from Jonathan M Davis <jmdavisProg@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: -------