This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2355 - op-subtract-dayTimeDuration-from-time-16 results are wrong
Summary: op-subtract-dayTimeDuration-from-time-16 results are wrong
Status: RESOLVED FIXED
Alias: None
Product: XML Query Test Suite
Classification: Unclassified
Component: XML Query Test Suite (show other bugs)
Version: 0.7.0
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Carmelo Montanez
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-18 15:14 UTC by Michael Kay
Modified: 2005-10-21 18:33 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2005-10-18 15:14:15 UTC
The published results of op-subtract-dayTimeDuration-from-time-16 are incorrect.

The query is:

(xs:time("09:06:07Z") - xdt:dayTimeDuration("P18DT02H02M")) ge  xs:time("01:01:01Z")

and the published result is: false. I believe the correct result is: true.

Rationale:

xs:time("09:06:07Z") - xdt:dayTimeDuration("P18DT02H02M")

evaluates to xs:time('07:04:07Z') which is greater than 01:01:01Z

Michael Kay
Comment 1 Michael Kay 2005-10-18 15:18:49 UTC
Similar problems affect

op-subtract-dayTimeDuration-from-time-15
op-subtract-dayTimeDuration-from-time-16
op-subtract-dayTimeDuration-from-time-17
Comment 2 Carmelo Montanez 2005-10-21 14:29:17 UTC
Mike:

Agree with some of your comments:

"op-subtract-dayTimeDuration-from-time-15" and
"op-subtract-dayTimeDuration-from-time-16" both should return true
However on "op-subtract-dayTimeDuration-from-time-17"

xs:time("12:07:08Z") - xdt:dayTimeDuration("P12DT10H07M")
evaluates to xs:time('02:00:08Z')
and xs:time('02:00:08Z') and fn:false() should evaluate to false.  Please tell 
me if I am overlooking/misundestanding something.  Please close bug if you 
agree with resolution.

Carmelo
Comment 3 Michael Kay 2005-10-21 14:52:51 UTC
I should have listed -17 under a different bug report. The query is

xs:time("12:07:08Z") - xdt:dayTimeDuration("P12DT10H07M") and fn:false()

and it fails because the LH operand of "and" is an xs:time, and taking the
effective boolean value of an xs:time is a type error.

MK
Comment 4 Carmelo Montanez 2005-10-21 15:18:14 UTC
Thanks.  rather than changing the test, I will change its type to an
error tests, which expects a run-time error of FORG0006.  Hope this works.

Carmelo
Comment 5 Michael Kay 2005-10-21 15:29:33 UTC
You need to handle this one the same as those listed in 2352, they all have the
same error. If you change all of these to expect an error, then we're going to
lose an awful lot of useful test cases.
Comment 6 Carmelo Montanez 2005-10-21 18:33:13 UTC
Very true.  Will follow similar scheme as other ones.  Is still evaluates to 
false.  I used the string representation of the LH operation.

Carmelo