Mark Dickinson <dicki...@gmail.com> added the comment:
[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.) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue15443> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
