3859 2006-10-24 02:38:06 +0000 oops! in ·newDateTime· 2007-09-18 02:56:20 +0000 1 1 1 Unclassified XML Schema Datatypes: XSD Part 2 1.1 only Macintosh All RESOLVED FIXED thimble, easy P2 normal --- 1 davep cmsmcq www-xml-schema-comments oldest_to_newest 12596 0 davep 2006-10-24 02:38:06 +0000 In the description of ·newDateTime· one argument is described as: Tz : an ·optional· duration between -PT14H and PT14H, inclusive. However, the values of timezone coordinates ("properties") in the 7-property date/time model are counts of minutes, whereas durations are themselves pairs of numbers. We should say "an ·optional· integer between -840 and 840, inclusive". 14541 1 cmsmcq 2007-03-26 15:34:22 +0000 Two possible changes: 1. In the description of the arguments of newDateTime, say (as suggested in the description of the issue) "an optional integer between -840 and 840 inclusive", and add ", indicating an offset in minutes from UTC". 2. In para 2 of D.2.1, for "There is also a seventh integer property which specifies the timezone, which is conceptually a duration measuring the offset of times with that timezone from ·UTC·." read "There is also a seventh integer property which specifies the timezone, which is conceptually a duration indicating the offset, in minutes, of times with that timezone from ·UTC·." 14608 2 davep 2007-03-31 03:50:20 +0000 Today the WG decided to change the description of the Tz argument of newDateTime to read "an optional integer between -840 and 840 inclusive". They also decided to change in D.2.1 the description of the timezone property in the second paragraph, which now reads "There is also a seventh integer property which specifies the timezone, which is conceptually a duration measuring the offset of times with that timezone from UTC" to read "There is also a seventh integer property which specifies the timezone as the number of minutes that timezone is offset from UTC". Accordingly, this bug is hereby marked decided. (Inasmuch as I originated the bug, and I approve of the fix, when this bug fix is added to the status quo document and marked FIXED it should immediately be marked CLOSED.) 16659 3 cmsmcq 2007-09-18 02:56:20 +0000 The change proposed above was approved by the WG on 30 March 2007 at its face to face meeting in Cambridge. It is now reflected in the status quo version of the Datatypes spec. Accordingly, I am setting the disposition of this issue to RESOLVED / FIXED. If the originator of the issue would examine the change and let us know whether it satisfactorily resolves the problem or not, we'd be grateful. To signal that the resolution is acceptable, change the status of the issue to CLOSED. Otherwise, to signal that it's NOT acceptable, change the status to REOPENED (and tell us what's wrong). If we don't hear from you in the next three weeks, we'll assume that silence betokens consent, and close the issue ourselves.