digitalmars.D.bugs - [Issue 11353] New: core.time.Duration is missing to() conversion function
- d-bugmail puremagic.com (29/29) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11353
- d-bugmail puremagic.com (9/9) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11353
- d-bugmail puremagic.com (8/14) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11353
- d-bugmail puremagic.com (38/40) Oct 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11353
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
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
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
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.msecsYeah, 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