Time

Overview

If a site only has data in one time zone, then time is easy to understand. This is probably the most common usage as organizations often do not cross time zones. If data is coming from multiple time zones then it must be considered.

Usage

OED thought about the issue of time zones and considered alternatives. If someone in New York City, U.S.A has a meeting at 11:00 with people from around the city, then everyone should show up at 11:00. On the other hand, if the same person arranged a phone call with someone in Los Angles, U.S.A. then the person in Los Angles expects the call at 8:00 since they are three time zones behind (or 3 hours farther behind UTC). The way we deal with it in everyday life is to use time zones since clocks are normally set to the local time zone. As a result, web browsers and other applications often shift a time you receive to local time. This is why, if your system/application is set up this way, you see the correct local time even if a calendar appointment came from another time zone.

OED decided this is not the best view of time for use in the dashboard when readings (meter data) comes from different time zones. As an example of why, consider a meter collecting data in New York, U.S.A. and one half way around the globe (12 hours farther from UTC). If you had meter data for 20:00 for both then when you graphed it in a web browser in New York, you would see 20:00 for its meter data and 8:00 for the data from the other meter. Put another way, the data from the two locations would show up at different time points on the graph. This is correct in the sense that 20:00 occurred at different absolute times. However, when looking at meter data, the time of the day that it occurs seems more important than the exact moment in time that it occurs. Thus, OED will place at 20:00 all the meter data that has that local time no matter where in the world it occurred. This means that every meter showing 20:00 indicates it happened in the evening at the same point in the day (excluding issues of where you are in a time zone and shifts for daylight savings, etc.). Since usage often varies by where you are in the day, this was deemed the best choice and is used in OED.

There was another issue in allowing times to shift to local time. If two different people in different time zones did a line graph from the same site, they saw different looking graphs. The graphs were very similar but shifted by the hours that the time zones differed. This also impacted the other graphs where they all had slightly different values due to using slightly different times (and therefore values). OED felt that anyone, anywhere should see the same graphic for a given site and meter. This is another reason we do not shift to local time.

Mostly these issues are not visible to users. However, it can come up and OED wanted everyone to understand how OED deals with time.

Details

OED recognized that users might want to know the original time zone associated with data when it is exported for use outside of OED. OED plans to include the time zone in exported data in a future release. Note this information will be most valuable for the small fraction of sites that might have data that crosses time zones or if dealing with a meter that honors daylight savings time.