I expect the local time zone can generally be assumed, but this would handle Daylight Savings Time for us. Right now, the data for 11/4/2018 01:00 does not distinguish EDT and EST. We get 2 measurements for some devices in that hour. For devices that have only 1 measurement, especially those that occur in the middle of the group for the hour, we can’t tell which hour the measurement is for.
It would be nice to have that tightened up.
AFAICT, Excel will not accept time zones as part of a date time format. If we wish to cater to Excel, 2 fields could be included one with and one without time zone.
Interesting. The API has everything in UTC so that’s what I was assuming the data export was doing too. Learned something new
That said, just exporting the data in the Data Export in UTC would eliminate that need for an extra field and everyone can just adjust the UTC time to their local time zone
Good point. That would be simpler. And it eliminates the Excel issue. And it eliminates the fall processing headache of having data for a device twice in the same hour.
However, notice that you thought it was UTC.
I think there is value in being very clear about what it is right in the record. In fact, these days I’m including both IntervalStartTime and IntervalEndTime in my records (with time zones). Because who knows if DateTime is when the record was written or when the interval started? It’s surprising how hard it is to find that out sometimes. No one thinks to document it in a readily accessible place and you end up having to check it against other data to see what it is.
Maybe DateTime should be renamed to IntervalStartTime? We wouldn’t need IntervalEnd since we know all the intervals are 1 hour. – I THINK I checked to confirm that it is interval start time…
Just dealing with this one tonight as I combine years. Since Sense exports data for two different “2018-11-04 1:00:00” hours and two different “2017-11-05 1:00:00” hours, we really need the time zone info (in my case “PDT” and “PST”) to differentiate. I have added a kludgy fix in my import scripts to fix.
Also noted that export for a year gives midnight data into the next year. Not a huge issue, but you have to pay attention and de-duplicate when combining multiple years…
I never had to really think about what that extra hour, when we switch from daylight savings time to standard time, is named.l until this weekend. Had to pry into how Posix names each hour.
The good news is that I have a while before I need to deal with leap years or leap seconds !
