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
