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
{{ message }}
This repository was archived by the owner on Feb 21, 2023. It is now read-only.
I recently started using this very useful lib, and discovered a timezone issue in the format_data method.
Enedis data are located in Europe/Paris timezone. This means that during the hour change day, we can have 2 values more (in October) or 2 values less (in March) for a day.
The format_data method uses a simple relativedelta addition on a timezone naive datetime object, which introduces a shift of all values by one hour when hitting an hour change.
Example : There was an hour change on 28th October 2018. Asking for data with start=2018-10-28 and end=2018-10-29 will give 50 values, because the hour between 2AM and 3AM is doubled.
The only way I know to fix this is to switch to UTC and return the values in UTC as well because switching back to Europe/Paris for returned values would break data again in October (2 values will be lost during the doubled hour).
But changing the behaviour of the method can break existing programs that use the lib...
I am using the lib in a custom script to write data into InfluxDB, displayed in Grafana, and everything works well with this patch:
--- a/client.py 2019-05-05 11:06:42.958021515 +0200+++ b/client.py 2019-05-05 11:05:59.677447347 +0200@@ -2,6 +2,7 @@
import simplejson
import base64
import datetime
+import pytz
from dateutil.relativedelta import relativedelta
import requests
from fake_useragent import UserAgent
@@ -142,7 +143,9 @@
periode = data.get("periode")
if not periode:
return []
- start_date = datetime.datetime.strptime(periode.get("dateDebut"), "%d/%m/%Y").date()+ start_date = datetime.datetime.strptime(periode.get("dateDebut"), "%d/%m/%Y")+ start_date = pytz.timezone('Europe/Paris').localize(start_date)+ start_date = pytz.utc.normalize(start_date)
# Calculate final start date using the "offset" attribute returned by the API
inc = 1
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hello,
I recently started using this very useful lib, and discovered a timezone issue in the
format_data
method.Enedis data are located in Europe/Paris timezone. This means that during the hour change day, we can have 2 values more (in October) or 2 values less (in March) for a day.
The
format_data
method uses a simplerelativedelta
addition on a timezone naive datetime object, which introduces a shift of all values by one hour when hitting an hour change.Example : There was an hour change on 28th October 2018. Asking for data with
start=2018-10-28
andend=2018-10-29
will give 50 values, because the hour between 2AM and 3AM is doubled.The only way I know to fix this is to switch to UTC and return the values in UTC as well because switching back to Europe/Paris for returned values would break data again in October (2 values will be lost during the doubled hour).
But changing the behaviour of the method can break existing programs that use the lib...
I am using the lib in a custom script to write data into InfluxDB, displayed in Grafana, and everything works well with this patch:
The text was updated successfully, but these errors were encountered: