-
Notifications
You must be signed in to change notification settings - Fork 670
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No real nanosecond resolution provided by time_ns #1594
Comments
Rename |
This should also have some clear documentation here. |
@ocelotl IIRC you suggested using milliseconds for versions < 3.7 and nanos for >= 3.7 python versions. It could be possible that my span operations duration in ranges of tens of nanoseconds, then, wouldn't that be an issue for 3.5 and 3.6 versions? A quick look at the exporters reveals that they require nanoseconds timestamp for most of the transport mechanisms and micros in few formats. What is the major concern here is it the precision resolution or the |
Throwing in my unsolicited $0.02 into the ring, having been recently bit by something like this. Playing devil's advocate a bit here, can you actually trust sub-microsecond timestamps on python <3.7 to actually be meaningfully comparable in terms of causality? It's more of an open question than a rhetorical, really, but my intuition is "not if you really depend on it for strict ordering". For that you really need a logical clock (e.g. Lamport clock). Also I believe on Windows you need to do some funky stuff to get better than 16ms resolution (not sure how much cross-platform you good folks are aiming for but I figure it's worth mentioning).
+1. Time is really thorny. Lots of potential footguns. Personally, I would aim for a "best effort" time resolution and a big "your mileage may vary" caveat, since some consumers may rely on the implicit, incorrect assumption that |
Right now, we provide
time_ns
as a function that should return a timestamp with nanosecond precision:Nevertheless, PEP 0564 explicitly compares
time.time_ns
againsttime.time
and shows that they don't have the same resolution, the former being much better.I think the purpose of the code above is to provide an uniform path where users can get a function that provides a timestamp with nanosecond resoultion regardless of the interpreter being run but it is misleading, we are not providing the same resolution for all Python versions.
I understand that the spec has precision requirements for timestamps but I don't think it is in the scope of OpenTelemetry to concern itself with providing this kind of functionality. Also, it is problematic to have a function named
time_ns
that can make an user believe the time is actually being measured with nanosecond precision when this is not the case.I suggest we eliminate this function completely, it is out of the scope of OpenTelemetry, puts us in a difficult situation by offering it as part of our public API and it is something else that we have to maintain for the future.
The text was updated successfully, but these errors were encountered: