Back to all discussions

  •   almost 11 years ago

Green Button Timezone

Can we assume that the timezone of the start dates in the intervals is the local timezone of building being measured? Or - is there a way to determine the timezone from some other field in the green button data? Thanks!

  • 5 comments

  • Manager   •   almost 11 years ago

    Yes, the timezone for the interval start date is the local timezone of the meter, which is in the building being measured. On a related note, you may have noticed that some of the sample data from PG&E and SDG&E don't have addresses. Real Green Button data will always have the building address, so feel free to drop in a fake address for testing purposes.
    Thanks!
    Matthew

  •   •   almost 11 years ago

    How is daylight savings handled if interval start times are in the local time zone? I see that start times in PG&E sample data form a continuous sequence across DST begin/end boundaries, so whatever timezone is being used must be offset by one hour for half of the year. The usual solution to this problem is to keep all timestamps in UTC, so I am surprised this is not the case for the IntervalReading schema.

  • Manager   •   almost 11 years ago

    Thanks for adding to this discussion- I'd been meaning to update it. As I stated in the update this morning, PG&E Green Button data is actually published using eastern time, not the local zone.

    I don't think that answers your question, though. My understanding is that all Green Button data is recorded in Unix time, so seconds since January 1, 1970. That would account for the lack of a bump for daylight savings, as that would need to be added when converting from Unix time to something more human readable. This isn't my area of expertise, so I've passed this question along to NIST for confirmation.
    Thanks!
    Matthew

  •   •   almost 11 years ago

    Hi Matthew: Looks like this is still an open item . Specifically, the Start Times provided in sample files are UTC. Had it been correctly provided in the sample by PG&E, its conversion to PST using the 8-hour offset (or 7 hour) for daylight savings would have yielded local time in PG&E area. What you have noted is that it is off by 3-hours since UTC date stamp has been derived corresponding to EST. Am I stating it correctly or is it more confusing?

  •   •   almost 11 years ago

    A timestamp that really tracks local time rather than UTC (or some fixed offset relative to UTC) should have jumps of one hour twice a year for daylight savings. Neither the PG&E or the SDG&E samples that I have checked show these jumps, so my conclusion is that they not tracking local time. Instead, the PG&E data appears to be on EST while SDG&E is using PST, which means that the data is offset by one hour during daylight savings.

    Hopefully, a future revision of the GreenButton standard will require that timestamps be in UTC and provide the meter's local timezone in a header.

Comments are closed.