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

On Tue, 1 Mar 2005 14:10:11 -0500, Dave Peterson <davep@iit.edu> wrote:

> 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.

At the risk of provoking Dave to shouting and expletives again,
I have to say that with equal justice all these arguments apply
to using an integer to represent a timezone.

> 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.

"Error"? Which error is that? I don't see that you have identified
an error, sorry, only a preference. This is all an abstract model for
how we understand our datatypes.

> Must we replow this ground?

In the interests of alignment with QT, if for no other reason, yes.

> 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.)

I find this an incredible statement. All the functions that take
timezone arguments or produce timezones return durations, not integers.

In the abstract, one might say that this all calls for a new timezone
datatype, but so far neither us nor QT nor anyone else has been willing
to stand up and say that is worth the bother.

//Mary


-- 
//Mary