_convert_timestamp uses timezone information where it should not #250
Comments
|
Thank you for reporting the issue, I did not think of this! I'll label this as a bug. |
|
Is this already solved? Sounds like a major bug. |
|
This has caused me a serious headache in British Summer Time (GMT+1:00). The future timestamps lead to measurements being registered in InfluxDB so "SHOW MEASUREMENTS" and "SHOW SERIES" return results, but all "SELECT * FROM " will return success but will be empty. Very difficult to debug. |
|
I have been wondering why it looks like we have an hour delay in our live data. Sounds like something is not applying the daylight saving correctly! |
|
MR is merged. Isn't the issue solved? |
|
@sebito91 as you can see, I have solved this in my branch in october 2015 which is 2 years ago. I'll not try the new version, also because the project on my side has ended. |
When _convert_timestamp gets a datetime object with timezone data, it converts it to the system's default via timegm. Also when given a datetime object without timezone data, it assumes it to be the system's local timezone.
From this data, the timestamp is created. So the timestamp is always in local timezone.
This is wrong as influxdb requires UTC timestamps. This is especially important in my timezone (Europe/Berlin, currently +02:00) where current timestamps are inserted in influxdb's future and are not shown in queries.
The fix is to create timestamps from a datetime object that is converted to UTC first.
Our current workaround is to convert timestamps before calling line_protocol.make_lines like this:
time = int(mydatetimeobject.astimezone(pytz.UTC).replace(tzinfo=None).timestamp() * 1e9)
The text was updated successfully, but these errors were encountered: