Well as for the implementation, time.Now() falls back to a function implemented in the runtime.
You can review the C time implementation and the implementation for time·now in assembly (linux amd64 in this case). This then uses clock_gettime, which provides nano seconds resolution. On windows, this is realized by calling GetSystemTimeAsFileTime, which too generates nanoseconds (not as high res but nanoseconds).
So yes, the resolution depends on the operating system and you can't expect it to be accurate on every OS but the developers are trying to make it as good as it can be. For example, in go1.0.3, time·now for FreeBSD used gettimeofday instead of clock_gettime, which only offers millisecond precision. You can see this by looking at the value stored in AX, as it is the syscall id. If you take a look at the referenced assembly, you can see that the ms value is mulitplied by 1000 to get the nanoseconds. However, this is fixed now.
If you want to be sure, check the corresponding implementations in the runtime source code and ask the manuals of your operating system.
support.microsoft.com/en-us/help/188768/… this doc indicates the GetSystemTimeAsFileTime works with 100 nanosecond intervals, not nanoseconds
@GeorgePolevoy Of course the underlying unit is still nanoseconds. The clock uses a resolution of 100 ns, therefore it increments in 100ns steps which enables you to count in nanoseconds, although not as precise as a single nanosecond. Just as I said in the answer.