I'm reading the library reference for core.time and It says that the duration is taken in "hnsecs" and I cannot understand if we can change that and choose the precision. Does anyone know if we can do that?

On Friday, 9 July 2021 at 20:43:48 UTC, rempas wrote:

It is stored internally in "hnsecs", but you can convert it to other units using the total method [1]; for example, myDuration.total!"nsecs".

[1] https://dlang.org/phobos/core_time.html#.Duration.total

On Friday, 9 July 2021 at 20:54:21 UTC, Paul Backus wrote:

It doesn't work for me. I have the following code:

MonoTime start = MonoTime.currTime();
// Doing stuff
MonoTime end = MonoTime.currTime();
Duration dur = end - start;
dur = dur.total!"nsecs";

and I get the following error message:

"Error: cannot implicitly convert expression `dur.total()` of type `long` to `Duration`"

On Friday, 9 July 2021 at 21:13:02 UTC, rempas wrote:

Duration dur = end - start;
dur = dur.total!"nsecs";

What are you trying to do, assigning a nanosecond value to a Duration? The Duration already has that many nanoseconds in it.

On Friday, 9 July 2021 at 21:13:02 UTC, rempas wrote:

MonoTime start = MonoTime.currTime();
// Doing stuff
MonoTime end = MonoTime.currTime();
Duration dur = end - start;
dur = dur.total!"nsecs";

You cannot change the precision of Duration, it always counts in multiples of 100 nsecs. You can count how many multiples of other units fit into the same Duration using total, but it will just return a number, not a “converted” Duration.

toString will produce an easy readable string (more or less), as in https://run.dlang.io/is/baqKLG, where “hnsec” is the smallest unit. If you think hectonanosecond is a weird unit, then you are not alone, and it has been pointed out that it does not comply with SI.

— Bastiaan.

On 7/9/21 5:04 PM, Ali Çehreli wrote:

You can get better than hnsecs resolution with core.time.MonoTime, which can support whatever the OS supports.

However, Duration and SysTime are stored in hnsecs for a very specific reason -- range. Simply put, if you have a 64-bit integer, and you picked nanoseconds as the unit, you can store only 585 years of range. 10 ns gives you 5850 years, and 100 ns gives you 58k years. That should be good enough for all but the most esoteric calculations (given that a Duration is signed, this gives a range of roughly -29k years to 29k years).

Note also that hnsecs is the base unit for Windows high precision clocks, though their epoch is year 1600 instead of year 0.

-Steve

On Saturday, 10 July 2021 at 01:11:28 UTC, Steven Schveighoffer wrote:

Nice summary. hnsecs is a little weird but defensible given the range argument.

Down the road we might add a nanosecond timeline abstraction based on TAI with zero set to 1972 (when UTC was aligned with TAI IIUC). Range issues could be addressed by animating the long dormant cent. Any precision issues could be handled with fixed point pairs.

Doubles across the same timeline would work for casual applications.