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)); } -----
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)
(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
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.
TickDuration will soon be deprecated, and none of the other time stuff supports floating point. Anyone who wants that functionality can calculate the floating point values from the integral values that the types do provide. It's not something that most code should be doing, but the API makes it possible for those who care.