Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Should we drop trailing zeros on timestamps? #2977
Let me preface by saying this is less of an actual problem with the way the data is returned and more of a problem of perception. I know I was confused by this behavior, but not necessarily inconvenienced by it. I don't really have a strong opinion how we address it, but I would like to have a well-reasoned answer for those, like me, who find it initially jarring.
When returning the timestamp, we drop any trailing zeros. That obscures the precision with which the points were written. For example:
(I verified that JSON and CSV output formats also drop the trailing zeros.)
Note the third returned point has a timestamp of
When querying my data I cannot tell from the return whether I wrote that point at nanosecond precision
In discussion with @gunnaraasen he proposed a possible fix, although it would perhaps break the RFC3339 convention.
By default, return full nanosecond precision, e.g.
For those users that store at s, ms, or u precision that will mean a lot of trailing zeros, and meaningless ones at that. Although we store all timestamps to nanosecond precision, if the write accuracy is only in milliseconds the last six zeros have no significance.
To combat that we allow the user to specify the precision of the returned timestamps, and then note that precision by truncating the timestamp with the character. For example:
Precision in nanoseconds:
Alternately we could provide the precision in the column headers, e.g.
All points are stored in nanos but we do not store the write precision separately. In order to prevent lots of trailing zeros for points written in microseconds, milliseconds, or seconds it's good to drop the trailing zeros.
This is something to document, but no development action to take at this time.