Re: XSD 1.1 issue: when did timezones cease being durations?

At 9:46 AM -0500 050301, C. M. Sperberg-McQueen wrote:
>With some dismay, I discovered this morning that the
>treatment of the seven-property time model in our
>status-quo document describes the timezone component
>as as integer (representing a number of minutes).
>
>This is a change from 1.0, which describes timezones
>as durations, and it conflicts with the treatment of
>timezones in the QT data model.  (Since normalization
>and denormalization involve addition and subtraction
>of timezones to dateTime values, treating timezones
>as integers would lead to some inconvenience for F
>and O.)
>
>Perhaps I was asleep at the switch at the moment when
>we discussed this, in which case I apologize to
>the Working Group and anyone else concerned for failing
>to raise this issue then.  But I think this is an
>important, though small, issue.
>
>I propose that as a matter of some urgency the WG
>ask the editors to prepare a wording proposal changing
>timezones back to being durations.

THE REASON THEY WERE CHANGED IS SIMPLE:  TIMEZONES ARE NOT THE
SAME AS DURATIONS--THEY DON'T BEHAVE THE SAME WAY.  CALLING THEM
DURATIONS JUST BECAUSE THEY ARE SIMILAR TO DURATIONS IS WISHFUL
THINKING.  TIMEZONES ARE NO MORE DURATIONS THAN FLOATS ARE DECIMALS.

There are four things critical to timezones:  the lexical
mapping, the canonical mapping, the value itself, and the
algorithm for adding them to and subtracting them from
dateTime values.

Of these, the only thing that they *can* have in common with
is the value.  Since timezones aren't really durations, what
point is there in replacing an integer-valued property with
one whose value is a pair of integers, one of which is required
to be zero?

Pretending a timezone is a duration will--obviously--not confuse
people into thinking that you use duration lexical representations
for timezones.  People know better.  But it will confuse implementers
who will think that they can get correct results using the duration
addition-to-dateTimes algorithm.

This error was discovered early in the development of the 7-property
model, and was corrected a long time ago by ceasing to pretend that
timezones are duration.

Must we replow this ground?

As far as F&O is concerned--they treat timezones as integers too.
The only difference is that they have timezone integers that must
be between -50400 and 50400 and must be a multiple of 60 (and must
be divided by 60 before using them), whereas we have timezones that
must be integers that are between -840 and 840 and need not be
divided by 60 before using.  As for the algorithm, F&O, like Schema
1.0, specifies (I believe) the adding-duration-to-dateTime algorithm,
which gives the wrong answer when leap-seconds are concerned.

(The reason I say they treat timezones as integers is that they
ignore the structure of dayTimeDuration values, and pretend they
are simply integers.)
-- 
Dave Peterson
SGMLWorks!

davep@iit.edu

Received on Tuesday, 1 March 2005 19:12:30 UTC