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
We are working with data provided by someone else who used sensorToolkit to aggregate their sub-hourly air quality data into daily averages. The shared with us the daily average .csv files they say were created by sensorToolkit. These .csv files look like this:
2021-08-20T00:00:00+00:00,,,,,,
2021-08-21T00:00:00+00:00,20.853773662022178,Degrees (Centigrade),61.128749938238236,Percent (Relative Humidity),33.94285714285714,Micrograms per Cubic Meter
2021-08-22T00:00:00+00:00,20.87606973087087,Degrees (Centigrade),62.22907382740694,Percent (Relative Humidity),15.859294117647059,Micrograms per Cubic Meter
2021-08-23T00:00:00+00:00,22.036475363231848,Degrees (Centigrade),58.012639749617804,Percent (Relative Humidity),15.41559523809524,Micrograms per Cubic Meter
The day boundary datestamp specifies midnight UTC but the data are from California.
One of three things is happening:
daily averages were calculated in the UTC timezone and the timestamps are correct
averages were calculated in the “America/Los_Angeles” timezone and the timestamps are incorrect
averages were calculated using “Local Standard Time” (PST all year-round) and the timestamps are given as UTC because no LST timezone exists.
It would be nice if sensorToolkit allowed for averaging according to either "clock" time or "LST" and included the correct timezone name or UTC offset in the generated daily-average .csv files.
The text was updated successfully, but these errors were encountered:
Thanks for your question. Sensortoolkit converts time to UTC timezone and displays this in graphs as well. In a new update I will update the documentation to clear up this issue. Thanks for your suggestion to allow the user to choose UTC or LST and I will try to work on this improvement.
Thanks for responding. From your answer, I understand that daily averages are calculated using hours 0-23 in UTC. So these daily averages will not correspond to local-time daily averages. Is that correct?
Asking for a friend ...
We are working with data provided by someone else who used sensorToolkit to aggregate their sub-hourly air quality data into daily averages. The shared with us the daily average .csv files they say were created by sensorToolkit. These .csv files look like this:
The day boundary datestamp specifies midnight UTC but the data are from California.
One of three things is happening:
I reviewed the documentation at https://sensortoolkit.readthedocs.io/en/latest/index.html but was unable to find anything describing the timestamps used for daily averages.
It would be nice if sensorToolkit allowed for averaging according to either "clock" time or "LST" and included the correct timezone name or UTC offset in the generated daily-average .csv files.
The text was updated successfully, but these errors were encountered: