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

Dave:
Two points.

1.  I don't understand why timezones are not durations.  Surely, 5 hours and 30 minutes is
a duration or a dayTimeDuration.  You can argue that timezones are a subtype of dayTimeDuration
with special rules for arithmetic.

2.  F&O changed it behavior as of this morning.  The timezone component is now stored as
a dayTimeDuration e.g.  PT5h30m.

All the best, Ashok
 

> -----Original Message-----
> From: w3c-xml-schema-ig-request@w3.org 
> [mailto:w3c-xml-schema-ig-request@w3.org] On Behalf Of Dave Peterson
> Sent: Tuesday, March 01, 2005 11:10 AM
> To: C. M. Sperberg-McQueen; W3C XML Schema Comments list
> Cc: W3C XML Schema IG
> Subject: 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:23:32 UTC