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
Quote:
"@eLco Ah, now I know what caused it! When looking in the CSV file, I saw that this particular hour had a list of data points logged twice (after 02:59, it started all over again at 02:00). Looking back in my calendar made me realize that the raspberry Pi clock had been set back automatically due to Daylight saving time in Sweden at that exact time. Odd one!"
The text was updated successfully, but these errors were encountered:
One possible fix is to store all times internally as UTC time, and then use our own axis labeling for the time axis to convert UTC to local time (with DST changes.)
Or the server manages the conversion. To avoid ambiguity all times should be stored in UTC (e.g. as millis since the epoch.) The server can then convert these to local time for the user when the times are fetched.
I read through your issue tracker specifically for this case, glad to see you already have an item for it. As another use case for you, I noticed that the data was not being stored in UTC after I updated my Pi to the proper time zone for my area. Of course since the data is stored in a flat text file we can see when the timezone changed within the graph:
Tim Malstrom reported this behavior on the forum:

Quote:
"@eLco Ah, now I know what caused it! When looking in the CSV file, I saw that this particular hour had a list of data points logged twice (after 02:59, it started all over again at 02:00). Looking back in my calendar made me realize that the raspberry Pi clock had been set back automatically due to Daylight saving time in Sweden at that exact time. Odd one!"
The text was updated successfully, but these errors were encountered: