[
Lists Home |
Date Index |
Thread Index
]
Dare wrote:
> xs:duration is broken and should never have made it into the W3C XML
> Schema REC in the first place. Simple question; Is an xs:duration
> representing 3 months equivalent to an xs:duration representing 90
> days?
>
> On the other hand, xf:yearMonthDuration and xf:dayTimeDuration are
> fully ordered and can be sorted in the manner you described.
I forgot to bring up the fact that xs:dateTime etc. aren't fully
ordered either, so following the same logic as above we should have:
xf:dateTimeWithTimezone
xf:dateTimeWithoutTimezone
xf:dateWithTimezone
xf:dateWithoutTimezone
...
What the F&O WD does at the moment is treat xs:dateTimes without
timezones as being the same as xs:dateTimes with a UTC timezone, in
other words treating:
10:34:00
as if it were:
10:34:00Z
My understanding is that date/times without timezones are supposed to
be treated as if they specify a "local time", which is particularly
useful when you want to talk about things that happen at the same
local time each day, even when the timezone changes between summer and
winter.
For example, if, in July, I had a friend who lived in New York and she
said "there's a bus at 10:34:00" it would mean the same as her saying
"there's a bus at 10:34:00-04:00", whereas if I say, in November,
"there's a bus at 10:34:00" it would mean the same as me saying
"there's a bus at 10:34:00Z".
Of course when you schedule something down to the particular day, then
you can *know* what timezone is relevant. So I can tell my friend "my
plane touches down at 2002-11-29T09:45:00-05:00
(2002-11-29T14:45:00Z)" (I'll assume we're both geeks, so she
understands ISO 8601-formatted date/times). But if she sent off a
query to her nice XQuery-driven web service asking which buses I can
catch from the airport after 2002-11-29T09:45:00-05:00, a bus at
10:34:00 (local time -- no timezone) won't come up because 10:34:00Z
is before 14:45:00Z.
I don't particularly care that this gives *wrong* results (though of
course I do think that it would be better if it gave the right one),
but I do think that it's inconsistent, confusing and unhelpful to have
one set of partially ordered data types be totally ordered through an
arbitrary and sometimes inaccurate conversion (by assuming that local
time means UTC) but another partially ordered data type be split into
subtypes (which don't even cover the entire range of possible values).
I think that it would be better to have a consistent approach to
partially ordered data types. One of:
- creating subtypes that are ordered
- using three-valued logic
- performing an arbitrary conversion to give total ordering
(An arbitrary conversion in the case of xs:dateTime could be to
convert into a dayTimeDuration by assuming that P1Y equals P365DT4H
and P1M equals P30DT10H15M, or something rather more accurate in
seconds.) Personally I prefer either the second or third option since
(a) it means there are fewer data types cluttering the spec and (b) it
would mean that *all* durations could be handled, not just those that
are totally ordered.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
