In this scenario then would both be provided? Would the default be to use local time if the DST does not agree? From: Considine, Toby (Campus Services IT) [mailto:
Toby.Considine@unc.edu] Sent: Monday, May 30, 2011 8:46 PM To: Girish Ghatikar;
Toby.Considine@gmail.com Cc:
energyinterop@lists.oasis-open.org Subject: RE: [energyinterop] Vavailability and Business Schedules You are right that the TZID should be conformed up to once per message. Time zone communications can be quite large, and they really should fall into the existing RFC for a TimeZone server, which would let the local system make the appropriate queries. We could make a conformance statement to always use UTC, but I note that California is increasingly looking to Arizona renewables. All time is local, and to the end nodes, is in local time. Certainly my smart thermostat automatically shifted to daylight savings time automatically, as it supports me going to work, coming home, and other activities that are denominated in local time. I am sure that if the TOU pricing that my relatives have on their refrigerators in San Diego were denominated in UTC, they would find them even less comprehensible. The last time that the US changed DST begin time, there were two weeks of confusion as previously scheduled meetings would or would not shift time zone. I am told by the CalConnect folks that the primary issue was whether they knew what local Time Zone they had been scheduled in or not. There are reasonable use cases for Availability that will be representing user time. If only the building manager can approve DR, and he is only available to do so between 9:00 and 10:00, then that Notification Window should move with DST, not be fixed in UTC. Long and short: we need both UTC and local, we need to be sure which one we are using at a given time, and we may need to add conformance if we want a profile that always uses one or the other in a particular interaction. tc " It is the theory that decides what can be observed ." - Albert Einstein Toby Considine Chair, OASIS oBIX Technical Committee U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Facilities Technology Office University of North Carolina Chapel Hill, NC Email: Toby.Considine@ unc.edu Phone: (919)962-9073
http://www.oasis-open.org blog:
www.NewDaedalus.com From: Girish Ghatikar [mailto:
gghatikar@lbl.gov] Sent: Monday, May 30, 2011 8:29 PM To:
Toby.Considine@gmail.com Cc:
energyinterop@lists.oasis-open.org Subject: Re: [energyinterop] Vavailability and Business Schedules Hi Toby, Thanks for the update! The JIRA issue was originally raised by Bruce and I was merely looking it the calendaring schedule simplification within the EiEvent service. While, this is a good way to start using the WS-Cal elements natively (the original intent of WS-Cal TC and PAP 04), I was looking at further optimization of the WS-Cal parameters that will add more simplicity to the message payload and schemas (it's a WS-Cal TC issue, I think). Some comments, which I could submit in JIRA if necessary: 1. Use the xcal:tzid parameter at high level and have only underlying xcal:dtstart and xcal:dtend wrapped in it. Simplified example, <xcal:properties> <xcal:uid> <xcal:text>14574d52-b9a7-449b-a1cc-312db74ceeaa</xcal:text> </xcal:uid> <xcal:parameters> <xcal:tzid> <xcal:text>America/New_York</xcal:text> </xcal:tzid> </xcal:parameters> <xcal:dtstart> <xcal:date-time>2011-01-02T09:00:00</xcal:date-time> </xcal:dtstart> <xcal:dtend> <xcal:date-time>2011-03-31T00:00:00</xcal:date-time> </xcal:dtend> </xcal:properties> 2. The above will also add the xcal:tzid component to xcal:components that does not have a time zone currently (otherwise, it is needed!). 3. The end time indicated, I believe, is 12 AM and NOT 11 AM as mentioned in the text ( minor issue ) -- is it a 24 hours format? 4. The recurring rule, I believe, is MO, TU, WE, TH and NOT MO, WE, and TH as mentioned in the text ( minor issue ). 5. Finally, what does the xcal:tzid parameter offer that does not exist in xcal:components for our intended purpose? -- "establishes a schedule good for three months (2011-01 – 2011-3) in which there is availability from 9:00 to 11:00 (2 hours) every Monday, Wednesday, and Thursday as well as a schedule for every Friday from 3:00 – 4:00." Of course, we need a timezone element here as well (not if described at the higher level than xcal:properties, unless there is a use case to describe a DR event signal within multiple timezones and service providers, which I don't anticipate to be one signal) I may have more once I start digging through the code. Thank you! -Rish ---------- Forwarded message ---------- From: Toby Considine <
Toby.Considine@gmail.com > Date: Mon, May 30, 2011 at 4:42 PM Subject: [energyinterop] Vavailability and Business Schedules To:
energyinterop@lists.oasis-open.org Rish raised the issue of the business schedule in Jira issue ENERGYINTEROP-368 this morning.
http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-368 The business schedule has been replicated in EMIX and, in a slightly different form, into EnergyInterop. The underlying vavailability type in ws-calendar allows the representation of a recurring pattern of schedules over a period that can be either closed or open ended. The vavailability object itself is made up of a set of availability objects, each with a potentially different recurrence. The object below establishes a schedule good for three months (2011-01 – 2011-3) in which there is availability from 9:00 to 11:00 (2 hours) every Monday, Wednesday, and Thursday as well as a schedule for every Friday from 3:00 – 4:00. <xcal:vavailability xmlns:xs="
http://www.w3.org/2001/XMLSchema-instance " xmlns:xcal="urn:ietf:params:xml:ns:icalendar-2.0"> <xcal:properties> <xcal:uid> <xcal:text>14574d52-b9a7-449b-a1cc-312db74ceeaa</xcal:text> </xcal:uid> <xcal:dtstart> <xcal:parameters> <xcal:tzid> <xcal:text>America/New_York</xcal:text> </xcal:tzid> </xcal:parameters> <xcal:date-time>2011-01-02T09:00:00</xcal:date-time> </xcal:dtstart> <xcal:dtend> <xcal:parameters> <xcal:tzid> <xcal:text>America/New_York</xcal:text> </xcal:tzid> </xcal:parameters> <xcal:date-time>2011-03-31T00:00:00</xcal:date-time> </xcal:dtend> </xcal:properties> <xcal:components> <xcal:available xs:type="xcal:AvailableType"> <xcal:properties> <xcal:dtstart> <xcal:date-time>2011-01-02T09:00:00</xcal:date-time> </xcal:dtstart> <xcal:dtend> <xcal:date-time>2011-03-01T11:00:00</xcal:date-time> </xcal:dtend> <xcal:rrule> <xcal:recur> <xcal:freq>WEEKLY</xcal:freq> <xcal:byday>MO</xcal:byday> <xcal:byday>TU</xcal:byday> <xcal:byday>WE</xcal:byday> <xcal:byday>TH</xcal:byday> </xcal:recur> </xcal:rrule> </xcal:properties> </xcal:available> <xcal:available xs:type="xcal:AvailableType"> <xcal:properties> <xcal:dtstart> <xcal:date-time>2011-03-01T15:00:00</xcal:date-time> </xcal:dtstart> <xcal:dtend> <xcal:date-time>2011-03-01T16:00:00</xcal:date-time> </xcal:dtend> <xcal:rrule> <xcal:recur> <xcal:freq>WEEKLY</xcal:freq> <xcal:byday>FR</xcal:byday> </xcal:recur> </xcal:rrule> </xcal:properties> </xcal:available> </xcal:components> </xcal:vavailability> In EMIX, the Business Schedule was merely a name, used to “hide” its origins. In EnergyInterop, it is modified to allow a collection of intervals to be expressed as well. There is no need to express a collection of intervals as well. Availability objects can be created with no recurrence to meet the same need. In the example below, the schedule for from now until year end includes several one-time intervals, shown in this case with a dtStart and a duration. <xcal:vavailability xmlns:xs="
http://www.w3.org/2001/XMLSchema-instance " xmlns:xcal="urn:ietf:params:xml:ns:icalendar-2.0"> <xcal:properties> <xcal:uid> <xcal:text>18b5a310-b83a-495e-be77-e2717c5f5a36</xcal:text> </xcal:uid> <xcal:dtstart> <xcal:parameters> <xcal:tzid> <xcal:text>America/New_York</xcal:text> </xcal:tzid> </xcal:parameters> <xcal:date-time>2011-05-28T00:00:00</xcal:date-time> </xcal:dtstart> <xcal:dtend> <xcal:parameters> <xcal:tzid> <xcal:text>America/New_York</xcal:text> </xcal:tzid> </xcal:parameters> <xcal:date-time>2011-12-31T00:00:00</xcal:date-time> </xcal:dtend> </xcal:properties> <xcal:components> <xcal:available xs:type="xcal:AvailableType"> <xcal:properties> <xcal:dtstart> <xcal:parameters> <xcal:tzid> <xcal:text>America/Montreal</xcal:text> </xcal:tzid> </xcal:parameters> <xcal:date-time>2011-03-01T09:00:00</xcal:date-time> </xcal:dtstart> <xcal:duration> <xcal:duration>PT2H</xcal:duration> </xcal:duration> </xcal:properties> </xcal:available> <xcal:available xs:type="xcal:AvailableType"> <xcal:properties> <xcal:dtstart> <xcal:parameters> <xcal:tzid> <xcal:text>America/Montreal</xcal:text> </xcal:tzid> </xcal:parameters> <xcal:date-time>2011-03-02T14:00:00</xcal:date-time> </xcal:dtstart> <xcal:duration> <xcal:duration>PT4H</xcal:duration> </xcal:duration> </xcal:properties> </xcal:available> <xcal:available xs:type="xcal:AvailableType"> <xcal:properties> <xcal:dtstart> <xcal:parameters> <xcal:tzid> <xcal:text>America/Montreal</xcal:text> </xcal:tzid> </xcal:parameters> <xcal:date-time>2011-03-08T13:00:00</xcal:date-time> </xcal:dtstart> <xcal:duration> <xcal:duration>PT5H</xcal:duration> </xcal:duration> </xcal:properties> </xcal:available> </xcal:components> </xcal:vavailability> If we did the same with a collection of intervals, we would see the following <xcal:vcalendar xmlns:xs="
http://www.w3.org/2001/XMLSchema-instance " xmlns:xcal="urn:ietf:params:xml:ns:icalendar-2.0"> <xcal:components> <xcal:interval> <xcal:properties> <xcal:uid> <xcal:text>d13d2db1-a33a-47b4-93e4-10038dc87f28</xcal:text> </xcal:uid> <xcal:duration> <xcal:duration>PT2H</xcal:duration> </xcal:duration> <xcal:dtstart> <xcal:parameters> <xcal:tzid> <xcal:text>America/Montreal</xcal:text> </xcal:tzid> </xcal:parameters> <xcal:date-time>2011-03-01T09:00:00</xcal:date-time> </xcal:dtstart> </xcal:properties> </xcal:interval> <xcal:interval> <xcal:properties> <xcal:uid> <xcal:text>6538df20-e827-4abd-84e6-3e8076611e49</xcal:text> </xcal:uid> <xcal:duration> <xcal:duration>PT4H</xcal:duration> </xcal:duration> <xcal:dtstart> <xcal:parameters> <xcal:tzid> <xcal:text>America/Montreal</xcal:text> </xcal:tzid> </xcal:parameters> <xcal:date-time>2011-03-02T14:00:00</xcal:date-time> </xcal:dtstart> </xcal:properties> </xcal:interval> <xcal:interval> <xcal:properties> <xcal:uid> <xcal:text>1ecb427d-e2c4-44ed-9822-bc1d2e99382a</xcal:text> </xcal:uid> <xcal:duration> <xcal:duration>PT5H</xcal:duration> </xcal:duration> <xcal:dtstart> <xcal:parameters> <xcal:tzid> <xcal:text>America/Montreal</xcal:text> </xcal:tzid> </xcal:parameters> <xcal:date-time>2011-03-08T13:00:00</xcal:date-time> </xcal:dtstart> </xcal:properties> </xcal:interval> </xcal:components> </xcal:vcalendar> A further advantage of the vavailability over the array of intervals is that it may have a distinct begin and end date for the overall series. Such a being and end date could be tied to seasonal DR, to a Tariff, to an Opt In, to an Opt Out, etc. In Energy Interop, we have introduced it into market contexts and business rules as well. We use this for notification windows, i.e., foo weekday DR availability, there may be merely a 20 minute notification window. For weeknight DR, you can use availability to require that notification come in between 3-5 in the afternoon. If you wanted, the same market could create Weekend DR requiring notification between noon and 2 on Friday. There are many uses for this element, and we should, as asked by Rish, use it natively to avoid complicating the schemas. “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw. Toby Considine TC9, Inc TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Email:
Toby.Considine@gmail.com Phone: (919)619-2104
http://www.tcnine.com/ blog:
www.NewDaedalus.com -- Rish Ghatikar Lawrence Berkeley National Laboratory 1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720
GGhatikar@lbl.gov +1 510.486.6768 +1 510.486.4089 [fax] This email is intended for the addressee only and may contain confidential information and should not be copied without permission. If you are not the intended recipient, please contact the sender as soon as possible and delete the email from computer[s].