Handle negative timestamps #4500
Conversation
|
What does a negative timestamp actually mean now? |
|
A negative timestamp is the number of nanoseconds earlier than the epoch. Right now, the line protocol does not support writing timestamps earlier than Also added a couple tests added to confirm the upper and lower bounds that the line protocol will parse (e.g. the max and min int64 values). |
|
I guess I am wondering why we would support this, but I guess if we can code for it without much work, it's OK. cc @jwilder |
|
As opposed to just rejecting the point. |
|
+1 on the code, not so sure about whether we shouldn't instead kick back an error. |
|
It does double the supported time range with minimal cost. |
|
@otoolep 0.9 has always supported negative timestamps for writes and reads. This fixes a bug in the line protocol where it threw an error when parsing a negative epoch timestamp. The JSON write path still happily allows negative timestamps and the entire query engine is fine with it. |
|
When this is merged we need to update the docs |
|
OK, thanks @beckettsean -- sounds like this should be merged. |
gunnaraasen
force-pushed
the
ga-time-bounds
branch
from
8118233
to
44c5e33
Compare
| if err == nil { | ||
| t.Fatalf("ParsePoints failed: %v", err) | ||
| } | ||
| _, err = models.ParsePointsString("cpu value=1 -1?") |
There was a problem hiding this comment.
Maybe add a test of 1- as well. Looks like that should pass but good for coverage.
|
Small test suggestion but 👍 otherwise. |
|
Added the suggested test. Going to merge on green. |
Handle negative timestamps
Fixes #3367.