Reading the standard, the key reference I see to timestamps is RFC3339 “Date and Time on the Internet: Timestamps”. This standard clearly states that UTC is the default and preferred representation. In the ESPI standard, this is referred only in the communication specifications section 21.6.2: “Date and time values for the above parameters use RFC 3339 format.” For the standard, timestamps in general are based on TimeType which does not make reference to locale. So I would say that the standard is not explicit but implies that all times are UTC.

martin.burns (5/21/2012 11:27 AM): Here is a proposed solution -- Based on similar SEP 2 time info data structure. Add a new entry that points up to UsagePoint to contain the LocalTimeParameters for the location of the UsagePoint. Ron Pasquarelli and I have prototyped this approach and works well. All timestamps in the Green Button data file are in UTC reference. The timezone in the LocalTimeParameters can be used in the presentation of the data in local format relative to the source of the data (the UsagePoint). Here is what the entry would look like in an ESPI data file. urn:uuid:89E62972-7229-4BAA-A971-E39C04E5722F DST For North America B40E2000 3600 360E2000 -18000 1899-12-30T00:00:00Z 1899-12-30T00:00:00Z Contains attributes related to the configuration of the time service. Rule to calculate end of daylight savings time in the current year. Result of dstEndRule must be greater than result of dstStartRule. Daylight savings time offset from local standard time. Rule to calculate start of daylight savings time in the current year. Result of dstEndRule must be greater than result of dstStartRule. Local time zone offset from UTCTime. Does not include any daylight savings time offsets. Bit map encoded rule from which is calculated the start or end time, within the current year, to which daylight savings time offset must be applied. The rule encoding: Bits 0 - 11: seconds 0 - 3599 Bits 12 - 16: hours 0 - 23 Bits 17 - 19: day of the week 0 = not applicable, 1 - 7 (Monday = 1) Bits:20 - 24: day of the month 0 = not applicable, 1 - 31 Bits: 25 - 27: operator (detailed below) Bits: 28 - 31: month 1 - 12 Rule value of 0xFFFFFFFF means rule processing/DST correction is disabled. The operators: 0: DST starts/ends on the Day of the Month 1: DST starts/ends on the Day of the Week that is on or after the Day of the Month 2: DST starts/ends on the first occurrence of the Day of the Week in a month 3: DST starts/ends on the second occurrence of the Day of the Week in a month 4: DST starts/ends on the third occurrence of the Day of the Week in a month 5: DST starts/ends on the forth occurrence of the Day of the Week in a month 6: DST starts/ends on the fifth occurrence of the Day of the Week in a month 7: DST starts/ends on the last occurrence of the Day of the Week in a month An example: DST starts on third Friday in March at 1:45 AM. The rule... Seconds: 2700 Hours: 1 Day of Week: 5 Day of Month: 0 Operator: 4 Month: 3