(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.
DST For North America
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.
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...
Day of Week: 5
Day of Month: 0
(4/6/2012 8:07 AM
): An ESPI data file as used for Green Button, for example, currently has no time zone information. The third party will not necessarily know the time zone that the data is for (the UsagePoint). Therefore, he can't render it to the Retail Customer in the appropriate time zone.
Therefore it seems reasonable that the data must have only UTC and that time zone and DST information needs to be added to the UsagePoint definition.
I suppose alternatively, a hint at the time zone information could be deduced from the atom publishing part of the data but this seems unsatisfying as it is header information that might not be retained in a user's application.
(3/19/2012 4:48 PM
): RFC 3339 is only used "for the above parameters" which are published and updated max and min (query parameters). Atom (RFC 4287) defines published and updated using xsd:dateTime, which is similar to ISO 8601 (allows specification of time zone), and ESPI uses "TimeType" which is similar to unix time (UTC / no time zone). If the field in question allows specification of a time zone, then times can be specified in relation to a specific time zone, but it is not required. The service provider (DataCustodian) does not need to know the time zone of the service consumer (AuthorizedThirdParty). The third party may need to convert times specified without time zone to local time for display purposes.