[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: WS-Calendar
|
The blog entry is very relevant – those are the guys who
are working on it. Cross-time zone behavior is integral to ICalendar-based
interactions. The team, led by RPI, includes calendar talent from Apple,
Microsoft and Apple. FIX Protocol and ISO 20022 (financial instruments) folks
were very much in presence at the event. The WS component they produce will
have a fast track to support by enterprise scheduling systems. I was pleased to have introduced the Calendar Consortium to the ISO
20022 folks. The began talks at the show about adoption / alignment of their
work. Version 1.1 of the oBIX is looking forward eagerly to adopting /
incorporating the same calendar object. I have long looked toward building
systems interacting with enterprise activities and schedules without additional
data entry. Think of it, common scheduling between the internet of things
and the enterprise, with a common message understandable to -
Energy -
Building Systems -
The Enterprise -
Finance Of course, the ICAL format implies the ICAL semantics, which are
performance based. I should be in that conference room, on that phone call at
9:00 and stay there until 10:00. The conference room should be cooled down by
9:00 and stay cooled down until 10:00. That energy price should be available at
9:00 and until 10:00. I should complete shedding that load by 9:00 and keep
that load shed until 10:00. Of course, when scheduling a meeting, all participants are
responsible for their own lead times. tc "A man should never be ashamed to own that he has been in
the wrong, which is but saying ... that he is wiser today than yesterday."
-- Jonathan Swift
From: Wilson, David C
(St. Paul) [mailto:DavidCWilson@trane.com] I read with
interest Toby’s recent post about WS-Calendar as well as his blog entry: http://www.newdaedalus.com/articles/2009/1/24/coordinating-time-and-energy.html I saw
references to WS-Calendar in the NIST notes as well. I’m hoping
Toby or others can elaborate on what such a specification bring over and above
the current data types available from XML Schema. I can easily
picture interval based pricing like the Texas pricing I reviewed with the TC: -Interval --StartTime
xs:dateTime --Interval
xs:duration --Price
xs:decimal What would a
WS-Calendar specification bring? Also, will that specification appropriately
deal with “naļve”
/ local time (a
time without a timezone)? In building protocols such as BACnet, schedules are
defined to start given local time with the responsibility of the device clock to be aware
of the current local time. Regards, Dave p.s.
I’ve observed a challenge with C#, it doesn’t seem to have a naļve time type and will
assume that a time without a timezone is local to the server. But if that time is
serialized and passed to another timezone, it will be unserialized with an adjustment
for timezone (i.e. if you set dateTime = 4 am on a server in Chicago, pass it
to a server in New York, it will unserialize as 5 am.) This detail
probably isn’t appropriate for this list, but it is an example of the complexities when
you use
times across systems. Enterprise
Solutions Portfolio Manager Trane
Commercial Systems Ingersoll
Rand Office:
+1.651.407.4168 Mobile:
+1.612.741.2759 Email:
davidcwilson@trane.com The information contained in this message is privileged and
intended only for the recipients named. If the reader is not a representative
of the intended recipient, any review, dissemination or copying of this message
or the information it contains is prohibited. If you have received this message
in error, please immediately notify the sender, and delete the original message
and attachments. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]