[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Vavailability and Business Schedules
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] 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
From: Girish Ghatikar [mailto:gghatikar@lbl.gov] 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 ---------- 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.”
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]