Fix off-by-100 error in time_ns() docstring

[LilithHafner]

How long does it take for an unsigned 64-bit integer counting nanoseconds to wrap?

2.0^64 nanoseconds
2.0^64/1e9 seconds
2.0^64/1e9/60 minutes
2.0^64/1e9/60^2 hours
2.0^64/1e9/60^2/24 days
2.0^64/1e9/60^2/24/365.25 years

584.5420460906265 years.

Round to 585.

Not sure where 5.8 came from.

To double check,

From wikipedia

Date range cutoffs are not an issue with 64-bit representations of Unix time, as the effective range of dates representable with Unix time stored in a signed 64-bit integer is over 584 billion years, or 292 billion years in either direction of the 1970 epoch.

presumably referring to counting seconds. Switching to nanoseconds shaves off a billion.

[kimikage]

Good catch! Consequently, I think your point is correct.

In general, the internal implementation might result in a shorter cycle.
time_ns() calls jl_hrtime().

julia/src/sys.c

Lines 503 to 508 in dfca90f

	// -- high resolution timers --
	// Returns time in nanosec
	JL_DLLEXPORT uint64_t jl_hrtime(void) JL_NOTSAFEPOINT
	{
	return uv_hrtime();
	}

jl_hrtime() calls uv_hrtime()
https://docs.libuv.org/en/v1.x/misc.html#c.uv_hrtime

There are no guarantees regarding the cycle.
However, its internal implementation seems to be more concerned with overflow avoidance than precision, so 585 years seems more reasonable than 5.8 years.

I don't really understand the nuances of the English language, but the conjunction "and" seems a bit strange to me.
I mean:

The time wraps every 585 years, but the time corresponding to 0 is undefined.

The first overflow "could" be 1ns later.

[KristofferC]

Taking some of the docstring from libuv might be a good idea https://docs.libuv.org/en/v1.x/misc.html#c.uv_hrtime. The part about "It is relative to an arbitrary time in the past." feels more clear than the current wording about "the time corresponding to 0 is undefined".

And the line "The primary use is for measuring performance between intervals." makes mentioning the overflow behavior pointless since you will get the right interval anyway.

(for fun, the commit that added the docstring is 5e627b214c3601c5772530878b6).

[LilithHafner]

Feel free to make further improvements to the docstring. I won't delay merging the bug/typo fix for that, though.