Include time zone in data export


#1

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.


#2

I’m pretty sure all times in the data export are UTC


#3

Data Export times are actually local time. Good call on a DST field, @duanetiemann. I’ll pass it along to the team.


#4

Interesting. The API has everything in UTC so that’s what I was assuming the data export was doing too. Learned something new :slight_smile:

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 :slight_smile:


#5

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…