How to limit support for xs:datetime and friends
Microsoft SQL XQuery PM and fellow SQLJunkies blogger Michael Rys really needs our input about how to do the serialization of Date and Time types in Yukon and forward. This was orginially posted to the Yukon beta newsgrouips, but I'm posting it here to help spread the word. Folks, I can't stress enough how important this is: here's your chance to directly affect how XQuery within Yukon will work. The pain you save may very well be your own! Also, this a great opportunity to show well the blogsphere works as a feedback tool to Microsoft.
The following is a slightly edited version of what Michael originally posted. The edits were made to make the survey suitable to this format.
Situation Description
The current semantics of xs:datetime, xs:date and xs:time in the W3C XQuery Working Drafts require to preserve presence or absence and exact value of the timezone information. Unfortunately, we cannot provide a full implementation of this type in the SQL Server 2005 timeframe since such representation is not byte-orderable. The Beta2 implementation is accepting all values, but normalizes all of them to UTC, even the local values that have no TZ values and loose roundtripping.
In order to be more forwards-compatible with the standard and to be better prepared to support different customer-scenarios, we would like to limit the values accepted for the types in Beta3 and RTM. In order to make the right decision, we have prepared the following mini-questionnaire to gather user feedback.
Please indicate which of the following plan/expect on using:
Q1. Of the three types xs:datetime, xs:date and xs:time, how are you planning to use them:
xs:datetime:
- Plan on using it and mix timezone and local values without timezones
- I plan on using it with timezone information only (e.g., 2004-08-01T12:12:12-08:00)
- I plan on using local values without timezone information only (e.g., 2004-08-01T12:12:12)
xs:date:
- I plan on using it and mix timezone and local values without timezones
- I plan on using it with timezone information only (e.g., 2004-08-01T12:12:12-08:00)
- I plan on using local values without timezone information only (e.g., 2004-08-01T12:12:12)
xs:time:
- I plan on using it and mix timezone and local values without timezones
- I plan on using it with timezone information only (e.g., 2004-08-01T12:12:12-08:00)
- I plan on using local values without timezone information only (e.g., 2004-08-01T12:12:12)
Q2. If you use timezone information,
- I expect the original TZ information to be preserved (e.g., 2004-08-01T12:12:12-08:00 will be returned as 2004-08-01T12:12:12-08:00)
- I can live with getting TZ information normalized to UTC (e.g, 2004-08-01T12:12:12-08:00 will be normalized to 2004-08-01T20:12:12Z)
Q3. If you use local values without timezone information, do you expect the absence of TZ information to be preserved for roundtripping?
Q4. Please select your preferred alternative that you want to see us implement in SQL Server 2005 (assuming that we cannot give you everything):
- Alt 1: When inserting xs:datetime values, we require timezone information. Values that do not have timezone information will be rejected. All values will be normalized to UTC and original timezone information will not be preserved. When inserting xs:time and xs:date, we reject values with timezone information and only accept values without timezone information. The absence of timezone information of the value will be preserved when returning the value. Plus/Minus of Alt 1:
- + Enables both absolute global and relative local uses of dates and times.
- + Equivalent to former utcdatetime/time/date support for storage.
- + Enables use of time values for relative local time usages such as <dailyschedule><wakeup>8:00:00</wakeup></dailyschedule>
- - Requires workarounds for covering flight schedule scenario <flight><dep>12:00:00-08:00</dep><arr>13:00:00-10:00</arr></flight>
- - Looses original TZ (and is thus not completely forward compatible)
- Alt 2:When inserting xs:datetime and xs:time values, we require timezone information. Values that do not have timezone information will be rejected. All values will be normalized to UTC and original timezone information will not be preserved. When inserting xs:date, we reject values with timezone information and only accept values without timezone information. The absence of timezone information of the value will be preserved when returning the value. Plus/Minus of Alt 2:
- + provides coverage of the main usecase for using xs:date (rarely requires timezone information)
- + Provides support for flight schedule scenario
- - Will disable use of xs:time Datatype for relative local time usages (workaround is to use xs:string)
- - does not provide both absolute global and relative local uses of dates and times.
- - Looses original TZ (and is thus not completely forward compatible)
- Alt 3: When inserting xs:datetime, xs:date, xs:time values, we require timezone information. Values that do not have timezone information will be rejected. All values will be normalized to UTC and original timezone information will not be preserved. Plus/Minus of Alt 3:
- + Provides support for flight schedule scenario
- + Simple rule to remember
- - requires TZ information on xs:date (that rarely requires timezone information)
- - Will disable use of xs:time Datatype for relative local time usages (workaround is to use xs:string)
- - does not provide both absolute global and relative local uses of dates and times.
- - Looses original TZ (and is thus not completely forward compatible)
- None of these alternatives are acceptable. Please provide your requirement below
Please send the filled out survey per email to mrys at microsoft dot com or reply below. We would appreciate to receive feedback by August 27, 2004.
If you could format your responses like the following, I'm sure the team would appreciate it:
Q1: xs:datetime-X, xs:date-Y, xs:time-Z (where X, Y and Z are the numbers corresponding to your choices)
Q2: X (where X is the numbers corresponding to your choice)
Q3: Yes or no. If you feel the need to elaborate, please do so.
Q3: Alt1, Alt2, Alt3 or provide a description of your alternative choices.
Thanks much!