Resolution of core.time.Duration...

[Alexander]

On 17.05.2011 15:25, Steven Schveighoffer wrote:

> if you use hnsecs, then you get a range of SysTime of -30k to 30k years.  That might seem overkill, but consider that even going to dnsecs (10 nanoseconds) reduces your range to -3k to +3k years.  The problem is that nobody is likely to care about
> that extra 10 intervals, but losing out on 27,000 years x 2 is pretty significant.  It seems like a no-brainer to me.

  Well, if you put it this way, it seems reasonable.

> Plus, we have good precedence, both Microsoft and Tango use that tick duration.  It's a natural conclusion.

  Linux/Posix are using ns (clock_gettime(), nanosleep() etc - timespec) - I guess there is a reason for this.

> Again, the resolution of the *structure* may be nsecs, but the actual intervals you have access to is about every 4ms on linux ( see http://en.wikipedia.org/wiki/Jiffy_(time) ).

  Not really. Take a difference from two consecutive get_clock() calls on Linux, and you will see that it is far below 1 µs (depends on CPU, though). Not all systems use timer interrupt for timekeeping.

> I agree that accepting a long as an alternative to Duration, it makes sense to use a more normal tick resolution.  The chances of someone wanting to have their process sleep for more than 300 years (e.g. for nanosecond resolution) is pretty small. 
> This might be a worthwhile change.

  Well, this is, actually, the whole reason of my post :) While 100ns resolution seems reasonable (after your explanations), accepting 100ns intervals as values directly seems not really good idea.

/Alexander