Thanks for your answers, that was very informative!

> >>> a/10**9
> 1580301619.9061854
> >>> a/1e9
> 1580301619.9061852
>
> I'm not sure which one is "correct".


Originally, I thought `a/10**9` was more precise because I ran into the following case while working with hundreds of nanoseconds (because windows):

```
r = 1580301619906185900
print("Ref   :", r)
print("10**7 :", int(r // 100 / 10**7 * 10 ** 7) * 100)
print("1e7   :", int(r // 100 / 1e7 * 10 ** 7) * 100)
print("10**9 :", int(r / 10**9 * 10**9))
print("1e9   :", int(r / 1e9 * 10**9))
[...]
Ref   : 1580301619906185900
10**7 : 1580301619906185800
1e7   : 1580301619906186200
10**9 : 1580301619906185984
1e9   : 1580301619906185984
```

I decided to plot the conversion errors for different division methods over a short period of time. It turns out that:
- `/1e9` is equally or more precise than `/10**9` when working with nanoseconds
- `/10**7` is equally or more precise than `/1e7` when working with hundreds nanoseconds

This result really surprised me, I have no idea what is the reason behind this.

See the plots and code attached for more information.

In any case, this means there is no reason to change the division in `_PyTime_AsSecondsDouble`, closing this issue as wontfix sounds fine :)

---

As a side note, the only place I could find something similar mentioned in the docs is in the `os.stat_result.st_ctime_ns` documentation: 

https://docs.python.org/3.8/library/os.html#os.stat_result.st_ctime_ns

> Similarly, although st_atime_ns, st_mtime_ns, and st_ctime_ns are 
> always expressed in nanoseconds, many systems do not provide 
> nanosecond precision. On systems that do provide nanosecond precision,
> 1the floating-point object used to store st_atime, st_mtime, and 
> st_ctime cannot preserve all of it, and as such will be slightly 
> inexact. If you need the exact timestamps you should always use 
> st_atime_ns, st_mtime_ns, and st_ctime_ns.

Maybe this kind of limitation should also be mentioned in the documentation of `time.time_ns()`?