[Alexander]

> Is there high enough demand for nanoseconds in datetime and time instances?

One need that we've encountered in real code is simply for compatibility. We have Python code that interacts with a logging web service whose timestamps include nanosecond information. Whether or not nanosecond resolution makes sense for those timestamps is a moot point: that's out of our control.

When representing information retrieved from that web service in Python-land, we have a problem. If datetime.datetime had nanosecond precision, then using datetime.datetime to represent the retrieved values would be a no-brainer. As it is, we face a choice between:

- truncating or rounding to microsecond precision, and losing information as a result (which is particularly problematic if we want to write records back at any point)
- representing in some indirect form (as a str, an integer number of nanoseconds, a (datetime, nanoseconds) tuple, ...) and requiring the user to convert values for plotting or other analysis
- writing our own non-standard ns-supporting datetime class, or looking for a 3rd party library with that support

None of those choices are terrible, but none of them are particularly palatable compared with using a standard library solution. (FWIW, we went with option 2, returning nanoseconds since the Unix epoch as an int.)