You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Timestamps would be parsed as Unix epoch seconds.fractional_seconds at down to nanosecond precision.
Actual behavior:
The timestamps were being parsed without giving an error message, but were incorrect when imported to the database.
Additional info:
It turned out that the ParseTimestampWithLocation function in internal/internal.go was receiving a timestamp string with an exponent e.g. 1.5515752371385763e+09 . This was confusing the part of the function which splits the string into timeInt and timeFractional.
Fix:
The fix was to change one line in plugins/parsers/csv/parser.go inside the function parseTimestamp. I changed the line: tStr := fmt.Sprintf("%v", recordFields[timestampColumn])
to tStr := fmt.Sprintf("%.9f", recordFields[timestampColumn])
This retains (up to) nanosecond precision, but forces it not to give an exponent.
EDIT:
In my haste, I forgot to test this with integer timestamps. Of course forcing Sprintf to try to parse as a float causes integers to be parsed incorrectly. The final solution is slightly longer:
import "reflect"
...
var tStr string
k := reflect.ValueOf(recordFields[timestampColumn]).Kind()
if k == reflect.Float32 || k == reflect.Float64 {
tStr = fmt.Sprintf("%.9f", recordFields[timestampColumn])
} else {
tStr = fmt.Sprintf("%d", recordFields[timestampColumn])
}
The text was updated successfully, but these errors were encountered:
Relevant telegraf.conf:
System info:
Telegraf 1.10.3
Ubuntu 16.04 LTS
Steps to reproduce:
CSV contains Unix timestamps with fractional seconds with a large numver of decimal places.
Input csv file:
Expected behavior:
Timestamps would be parsed as Unix epoch seconds.fractional_seconds at down to nanosecond precision.
Actual behavior:
The timestamps were being parsed without giving an error message, but were incorrect when imported to the database.
Additional info:
It turned out that the ParseTimestampWithLocation function in internal/internal.go was receiving a timestamp string with an exponent e.g. 1.5515752371385763e+09 . This was confusing the part of the function which splits the string into timeInt and timeFractional.
Fix:
The fix was to change one line in plugins/parsers/csv/parser.go inside the function parseTimestamp. I changed the line:
tStr := fmt.Sprintf("%v", recordFields[timestampColumn])
to
tStr := fmt.Sprintf("%.9f", recordFields[timestampColumn])
This retains (up to) nanosecond precision, but forces it not to give an exponent.
EDIT:
In my haste, I forgot to test this with integer timestamps. Of course forcing Sprintf to try to parse as a float causes integers to be parsed incorrectly. The final solution is slightly longer:
The text was updated successfully, but these errors were encountered: