Resolution of core.time.Duration...

[Jonathan M Davis]

On 2011-05-17 03:15, Alexander wrote:
> ...why it is in hnsec? I know that this resolution is used in Win32 API
> (file time), but since TickDuration may be 1 ns resolution, wouldn't it be
> better to make Duration to be stored with maximum (defined so far)
> resolution?
> 
> Especially because Duration may not hold long intervals (> months) - so
> there is no problem with overflow.
> 
> Thread.sleep() accepts Duration (or hnsec) as an argument, while system
> resolution is higher, and on some systems it is even possible that it can
> sleep less than 100ns.
> 
> SysTime is also kept in hnsecs, while resolution of system time (on Linux
> at least) is 1ns. Sure, in case of SysTime it is all bound to overflow,
> but it depends how value is stored - if we split seconds and nanoseconds,
> it will be fine.
> 
> Additionally, when accepting long values as an argument for duration it is
> more logically to use SI units :)
> 
> /Alexander

hnsecs is the highest resolution that you can hold in a 64-bit integer and 
still have it cover a reasonable range. And remember that a Duration is what's 
used as the result of subtracting one SysTime from another, so making it more 
precise would be bad. As it is, it can't actually hold the difference of 
SysTime.max - SysTime.min. Because it's signed, it can only hold half that 
range. Also, the system clock definitely does not reach hnsecs on any system 
that I've seen. It generally maxes out at microseconds or a bit better than 
that. So, in most cases, using a precision greater than hnsecs doesn't gain 
you anything. I'd love to have greater precision, but it would require 
something larger than a 64-bit integer, which we don't have. Or it would 
require splitting up the seconds and sub-seconds which makes the types take up 
more space and makes the math that much worse.

During the development and review process, it was decided that hnsecs was 
ideal. Sure, higher precision might be nice, but we don't have anything bigger 
than a 64-bit integer, and odds are that you couldn't really take advantage of 
the higher precision anyway.

- Jonathan M Davis