MonoTime longevity
I discovered something potentially troublesome in druntime. Namely, applications that use MonoTime will break if run 18 hours after booting, according to a short program I wrote. Here's my code: ``` import core.time : MonoTime; auto mt = MonoTime.currTime; import std.stdio : writeln; writeln(mt.ticks / mt.ticksPerSecond / 60 / 60); // prints 18 (hours) shortly after boot ``` `mt.ticksPerSecond` is `1_000_000_000` on my system. I really hope I'm doing something wrong.
Re: MonoTime longevity
On 12/22/15 2:48 PM, Tanel Tagaväli wrote: I discovered something potentially troublesome in druntime. Namely, applications that use MonoTime will break if run 18 hours after booting, according to a short program I wrote. Here's my code: ``` import core.time : MonoTime; auto mt = MonoTime.currTime; import std.stdio : writeln; writeln(mt.ticks / mt.ticksPerSecond / 60 / 60); // prints 18 (hours) shortly after boot ``` `mt.ticksPerSecond` is `1_000_000_000` on my system. I really hope I'm doing something wrong. MonoTime uses whatever precision is given to it by the OS. So if on your OS, ticksPerSecond is 1e9, then your OS clock wraps at 18 hours as well. In a recent version of D, MonoTime was changed to support multiple clocks. Use MonoTimeImpl!SomeClockType to use a clock with a different number of ticks per second if one exists. You can also use std.datetime.Clock -Steve
Re: MonoTime longevity
On Tuesday, 22 December 2015 at 20:07:58 UTC, Steven Schveighoffer wrote: MonoTime uses whatever precision is given to it by the OS. So if on your OS, ticksPerSecond is 1e9, then your OS clock wraps at 18 hours as well. Thanks, I didn't know that. I actually just realized that my use case doesn't need to rely on absolute clocks, so I'm safe.
Re: MonoTime longevity
On Tuesday, December 22, 2015 15:07:58 Steven Schveighoffer via Digitalmars-d-learn wrote: > MonoTime uses whatever precision is given to it by the OS. So if on your > OS, ticksPerSecond is 1e9, then your OS clock wraps at 18 hours as well. 1e9 ticks per second should still take over 293 years to wrap around. writeln(seconds(long.max / cast(long)1e9)); prints out 15250 weeks, 1 day, 23 hours, 47 minutes, and 16 secs Even if the clock ticks were in picoseconds (1e12 ticks per second), the clock would still take over 15 weeks to wrap around from 0. The OP's writeln(mt.ticks / mt.ticksPerSecond / 60 / 60); // prints 18 (hours) simply indicates that the system clock thinks that 18 hours have passed since the start of the system clock. And there's no guarantee that the system clock starts at 0, so while it's a bit weird for it to be in the range of 18 hours shortly after boot, it's perfectly legal. The only risk would be if the clock started close enough to long.max to cause the clock to wrap around even though it would have had plenty of room at 0. So, unless I'm missing something here, there is no problem, and MonoTime will work fine for what the OP is looking to do. As I recall, in the initial PR for Monotime, we discussed its range based on various clock frequencies and concluded that long was plenty large for any clock frequency we were ever going to see; otherwise, we probably would have gone with something similar to what POSIX uses (timespec) and split out the seconds and ticks per second rather than simply use ticks per second. - Jonathan M Davis
