Re: [saxon] xs:dateTime, plus sign is not permitted From: Frans Englich - 2006-02-07 18:49 ```On Tuesday 24 January 2006 12:14, Frans Englich wrote: > Hi, > > I think I've found a bug in the handling of lexical representations of > xs:dateTime. The following expression compiles: xdt:yearMonthDuration("P3Y36M") div xs:double("INF") xdt:yearMonthDuration("P3Y36M") div xs:double("-INF") xdt:dayTimeDuration("P3D") div xs:double("INF") xdt:dayTimeDuration("P3D") div xs:double("-INF") All evaluates to P0M and PT0S, respectively. The descriptions for op:multiply-dayTimeDuration and=20 op:multiply-yearMonthDuration reads: If \$arg2 is positive or negative infinity, the result overflows and is hand= led=20 as discussed in 10.1.1 Limits and Precision. 10.1.1 Limits and Precision reads: If a processor limits the number of digits allowed in the representation of= =20 xs:integer and xs:decimal then overflow and underflow situations can arise= =20 when it tries to execute the functions in 10.6 Arithmetic Functions on=20 Durations. In these situations the processor =B7must=B7 return zero in case= of=20 numeric underflow and P0M or PT0S in case of duration underflow. It =B7must= =B7=20 raise an error [err:FODT0002] in case of overflow. My conclusion is that for all the above expressions should FODT0002 be rais= ed=20 because overflows happens(for duration underflow P0M/PT0S is in order). Am = I=20 seeing this the right way? Frans ```

[saxon] xs:dateTime, plus sign is not permitted Frans Englich <frans.englich@te...>
 leading zeros prohibited [was Re: [saxon] xs:dateTime, plus sign is not permitted] From: Frans Englich - 2006-01-24 12:18 ```On Tuesday 24 January 2006 12:14, Frans Englich wrote: > Hi, > > I think I've found a bug in the handling of lexical representations of > xs:dateTime. I think here's another case: xs:dateTime("02004-08-01T12:44:05") It succeeds to compile, which I think is inconsistent with "if more than four digits, leading zeros are prohibited"(also from section 3.2.7.1). Again, this might apply to other types as well, I haven't investigated. Frans ```

 Re: [saxon] xs:dateTime, plus sign is not permitted From: Frans Englich - 2006-01-25 14:35 ```On Tuesday 24 January 2006 12:14, Frans Englich wrote: > Hi, > > I think I've found a bug in the handling of lexical representations of > xs:dateTime. I think I've found another case. The following expression succeeds to compile: xs:duration("+P1Y2M123DT10H30M99S") but 3.2.6.1 says "An optional preceding minus sign ('-') is allowed, to indicate a negative duration. If the sign is omitted a positive duration is indicated," which I interpret as that a preceding plus sign is prohibited. Since the XDM durations are restrictions of xs:duration the same applies. Thus, these casts should fail: xdt:yearMonthDuration("+P20Y15M") xdt:dayTimeDuration("+P3DT10H") Frans ```

 RE: [saxon] xs:dateTime, plus sign is not permitted From: Michael Kay - 2006-01-25 17:23 ```Yes, I think your interpretation of the spec is probably correct. ISO 8601 doesn't allow either a "+" or a "-" sign here. Michael Kay http://www.saxonica.com/ > -----Original Message----- > From: saxon-help-admin@... > [mailto:saxon-help-admin@...] On Behalf Of > Frans Englich > Sent: 25 January 2006 14:46 > To: saxon-help@... > Subject: Re: [saxon] xs:dateTime, plus sign is not permitted > > On Tuesday 24 January 2006 12:14, Frans Englich wrote: > > Hi, > > > > I think I've found a bug in the handling of lexical > representations of > > xs:dateTime. > > I think I've found another case. The following expression > succeeds to compile: > > xs:duration("+P1Y2M123DT10H30M99S") > > but 3.2.6.1 says "An optional preceding minus sign ('-') is > allowed, to > indicate a negative duration. If the sign is omitted a > positive duration is > indicated," which I interpret as that a preceding plus sign > is prohibited. > > Since the XDM durations are restrictions of xs:duration the > same applies. > Thus, these casts should fail: > > xdt:yearMonthDuration("+P20Y15M") > xdt:dayTimeDuration("+P3DT10H") > > > Frans > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. > DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&; > dat=121642 > _______________________________________________ > saxon-help mailing list > saxon-help@... > https://lists.sourceforge.net/lists/listinfo/saxon-help > ```

 Re: [saxon] xs:dateTime, plus sign is not permitted From: Frans Englich - 2006-01-25 23:10 ```On Tuesday 24 January 2006 12:14, Frans Englich wrote: > Hi, > > I think I've found a bug in the handling of lexical representations of > xs:dateTime. The following expression compiles: Some more in the similar vein. This expression succeds to compile: xs:duration("P") 3.2.6.1 reads: If the number of years, months, days, hours, minutes, or seconds in any=20 expression equals zero, the number and its corresponding designator =B7may= =B7 be=20 omitted. However, at least one number and its designator =B7must=B7 be pres= ent. I don't think the expression is consistent with the last sentence, and=20 therefore should be flagged as an error. =46rom my understanding the same applies to the sister types. Saxon treats = them=20 the same way, as xs:duration: xdt:yearMonthDuration("P") xdt:dayTimeDuration("P") Frans ```

 RE: [saxon] xs:dateTime, plus sign is not permitted From: Michael Kay - 2006-01-25 23:35 ```Thanks again - you are doing some very thorough testing! Now fixed. Michael Kay=20 > -----Original Message----- > From: saxon-help-admin@... > [mailto:saxon-help-admin@...] On Behalf Of=20 > Frans Englich > Sent: 25 January 2006 23:21 > To: saxon-help@... > Subject: Re: [saxon] xs:dateTime, plus sign is not permitted >=20 > On Tuesday 24 January 2006 12:14, Frans Englich wrote: > > Hi, > > > > I think I've found a bug in the handling of lexical=20 > representations of > > xs:dateTime. The following expression compiles: >=20 > Some more in the similar vein. >=20 > This expression succeds to compile: >=20 > xs:duration("P") >=20 > 3.2.6.1 reads: >=20 > > If the number of years, months, days, hours, minutes, or=20 > seconds in any=20 > expression equals zero, the number and its corresponding=20 > designator .may. be=20 > omitted. However, at least one number and its designator=20 > .must. be present. > >=20 > I don't think the expression is consistent with the last=20 > sentence, and=20 > therefore should be flagged as an error. >=20 > From my understanding the same applies to the sister types.=20 > Saxon treats them=20 > the same way, as xs:duration: >=20 > xdt:yearMonthDuration("P") > xdt:dayTimeDuration("P") >=20 >=20 > Frans >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep=20 > through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. =20 > DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=103432&bid#0486&dat=121642 > _______________________________________________ > saxon-help mailing list > saxon-help@... > https://lists.sourceforge.net/lists/listinfo/saxon-help >=20 ```

 Re: [saxon] xs:dateTime, plus sign is not permitted From: Frans Englich - 2006-01-27 14:03 ```On Tuesday 24 January 2006 12:14, Frans Englich wrote: > Hi, > > I think I've found a bug in the handling of lexical representations of > xs:dateTime. The following expression compiles: Ok, good ones this time. For the invalid expression 'xs:duration("P1Y24MT")' I get the backtrace below. Same applies to 'xdt:yearMonthDuration("P1Y24MT")'. Btw, I thought a about the canonical form of xs:duration. From what I can tell it's section 17.1.2 in F&O which specifies that the canonical form for P1Y24M is P3Y, for example. But if one couldn't rely on F&O, if one only had XML Schema Part 2, how would it be handled then? What's the story behind that part of the specification? Frans Saxon 8.6 from Saxonica Java version 1.4.2_04 java.util.NoSuchElementException at java.util.StringTokenizer.nextToken(StringTokenizer.java:259) at java.util.StringTokenizer.nextElement(StringTokenizer.java:316) at net.sf.saxon.value.DurationValue.(DurationValue.java:69) at net.sf.saxon.value.StringValue.convertStringToBuiltInType(StringValue.java:182) at net.sf.saxon.value.StringValue.convertPrimitive(StringValue.java:95) at net.sf.saxon.value.AtomicValue.convert(AtomicValue.java:137) at net.sf.saxon.expr.CastExpression.evaluateItem(CastExpression.java:262) at net.sf.saxon.expr.CastExpression.typeCheck(CastExpression.java:196) at net.sf.saxon.expr.CastExpression.simplify(CastExpression.java:167) at net.sf.saxon.instruct.Block.simplify(Block.java:160) at net.sf.saxon.expr.ExpressionTool.make(ExpressionTool.java:54) at net.sf.saxon.style.StyleElement.makeExpression(StyleElement.java:475) at net.sf.saxon.style.XSLValueOf.prepareAttributes(XSLValueOf.java:63) at net.sf.saxon.style.StyleElement.processAttributes(StyleElement.java:375) at net.sf.saxon.style.StyleElement.processAllAttributes(StyleElement.java:340) at net.sf.saxon.style.StyleElement.processAllAttributes(StyleElement.java:348) at net.sf.saxon.style.XSLStylesheet.processAllAttributes(XSLStylesheet.java:895) at net.sf.saxon.style.XSLStylesheet.preprocess(XSLStylesheet.java:622) at net.sf.saxon.PreparedStylesheet.setStylesheetDocument(PreparedStylesheet.java:279) at net.sf.saxon.PreparedStylesheet.prepare(PreparedStylesheet.java:117) at net.sf.saxon.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:130) at net.sf.saxon.Transform.doMain(Transform.java:435) at net.sf.saxon.Transform.main(Transform.java:60) Fatal error during transformation: null ```

 Re: [saxon] xs:dateTime, plus sign is not permitted From: Colin Paul Adams - 2006-01-27 14:51 ```>>>>> "Frans" == Frans Englich writes: Frans> Btw, I thought a about the canonical form of Frans> xs:duration. From what I can tell it's section 17.1.2 in Frans> F&O which specifies that the canonical form for P1Y24M is Frans> P3Y, for example. But if one couldn't rely on F&O, if one Frans> only had XML Schema Part 2, how would it be handled then? Frans> What's the story behind that part of the specification? ISO 8601 is where it's specified, in general. I don't remember off the top of my head whether or not canonical forms are specified. -- Colin Adams Preston Lancashire ```

 RE: [saxon] xs:dateTime, plus sign is not permitted From: Michael Kay - 2006-01-27 16:14 ```> Ok, good ones this time. For the invalid expression > 'xs:duration("P1Y24MT")' I > get the backtrace below. Same applies to > 'xdt:yearMonthDuration("P1Y24MT")'. Thanks, fixed. > > Btw, I thought a about the canonical form of xs:duration. > From what I can tell > it's section 17.1.2 in F&O which specifies that the canonical > form for P1Y24M > is P3Y, for example. But if one couldn't rely on F&O, if one > only had XML > Schema Part 2, how would it be handled then? What's the story > behind that > part of the specification? Rather a muddle. According to schema, duration is a 6-tuple, so if you define an enumeration of permitted values then P1Y and P12M are not equal. They're fixing this in 1.1 by distinguishing identity of values from equality of values. Schema defines canonical forms for some types but not others; F+O has had to fill in the gaps where necessary. Michael Kay Saxonica Limited ```

 Re: [saxon] xs:dateTime, plus sign is not permitted From: Frans Englich - 2006-02-03 00:01 ```On Tuesday 24 January 2006 12:14, Frans Englich wrote: > Hi, > Similarly, I think these should evaluate to true, while they currently do not: xs:duration("-PT0S") eq xs:duration("PT0S") xdt:dayTimeDuration("-PT0S") eq xdt:dayTimeDuration("PT0S") xdt:yearMonthDuration("-P0M") eq xdt:yearMonthDuration("P0M") Michael, considering you're rewriting op:duration-equal in F&O, it could perhaps be an idea to add one of the above expressions as an example, in order to help with interpretation of this slightly corner cases. I also could be wrong, but I don't see why a distinction should be made. Frans ```

 Re: [saxon] xs:dateTime, plus sign is not permitted From: Frans Englich - 2006-02-03 00:17 ```On Tuesday 24 January 2006 12:14, Frans Englich wrote: > Hi, > > I think I've found a bug in the handling of lexical representations of > xs:dateTime. The following expression compiles: Ok, more cases. These expressions evaluate to false: xs:string(xdt:dayTimeDuration("-PT0S")) eq "PT0S" xs:string(xdt:yearMonthDuration("-P0M")) eq "P0M" While xs:string(xs:duration("-PT0S")) eq "PT0S" evaluates to true. I think the xs:duration case got it right. Frans ```

 RE: [saxon] xs:dateTime, plus sign is not permitted From: Michael Kay - 2006-02-03 19:02 ```Thanks, I've logged this as a bug and fixed it. Michael Kay http://www.saxonica.com/ > -----Original Message----- > From: saxon-help-admin@... > [mailto:saxon-help-admin@...] On Behalf Of > Frans Englich > Sent: 03 February 2006 00:12 > To: saxon-help@... > Subject: Re: [saxon] xs:dateTime, plus sign is not permitted > > On Tuesday 24 January 2006 12:14, Frans Englich wrote: > > Hi, > > > > Similarly, I think these should evaluate to true, while they > currently do not: > > xs:duration("-PT0S") eq xs:duration("PT0S") > xdt:dayTimeDuration("-PT0S") eq xdt:dayTimeDuration("PT0S") > xdt:yearMonthDuration("-P0M") eq xdt:yearMonthDuration("P0M") > > Michael, considering you're rewriting op:duration-equal in > F&O, it could > perhaps be an idea to add one of the above expressions as an > example, in > order to help with interpretation of this slightly corner > cases. I also could > be wrong, but I don't see why a distinction should be made. > > > Frans > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. > DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&; > dat=121642 > _______________________________________________ > saxon-help mailing list > saxon-help@... > https://lists.sourceforge.net/lists/listinfo/saxon-help > ```

 [saxon] IDREF From: Carmelo Montanez - 2006-02-03 20:03 Attachments: fn-idref-5.xq      id.xml ```Hey Michael: As per my comment yesterday after the meeting. attached is test for fn-idref, which is intended to be run also with the xml file (also attached). I am not sure I follow the message from Saxon: "Error while executing test : net.sf.saxon.trans.DynamicError: In the idref() function, the context node must be in a tree whose root is a document node " This may all be mute point as I may have to make this test schema dependent (or at least provide both a DTD and a schema version). Thanks, Carmelo ```

 RE: [saxon] IDREF From: Michael Kay - 2006-02-04 10:13 ```It does no harm to have the question on the list, and I'll follow it up on the list so the answer is there too. There are two Saxon problems shown up here. The first is a poor error message: when it refers to "the context node", it means in this case "the node supplied in the second argument". The second problem is more serious: Saxon is requiring that the second argument actually *is* the document node, it's not allowing you to supply any node within the tree. I'll register this as a bug and fix it. Michael Kay http://www.saxonica.com/ > -----Original Message----- > From: saxon-help-admin@... > [mailto:saxon-help-admin@...] On Behalf Of > Carmelo Montanez > Sent: 03 February 2006 20:02 > To: saxon-help@... > Subject: [saxon] IDREF > > Hey Michael: > > As per my comment yesterday after the meeting. attached is test > for fn-idref, which is intended to be run also with the xml file (also > attached). I am not sure I follow the message from Saxon: > > "Error while executing test : net.sf.saxon.trans.DynamicError: In the > idref() function, the context node must be in a tree whose root is a > document node " > > This may all be mute point as I may have to make this test schema > dependent (or at least provide both a DTD and a schema version). > > Thanks, > Carmelo > > ```

 Re: [saxon] xs:dateTime, plus sign is not permitted From: Frans Englich - 2006-02-07 17:58 ```On Tuesday 24 January 2006 12:14, Frans Englich wrote: > Hi, > The following expression evaluates to false, while I think it should evaluate to true: xdt:dayTimeDuration("P3DT4H3M3.100S") + xdt:dayTimeDuration("P3DT12H31M56.514S") eq xdt:dayTimeDuration("P6DT16H34M59.613999S") The expression(taken from above): xdt:dayTimeDuration("P3DT4H3M3.100S") + xdt:dayTimeDuration("P3DT12H31M56.514S") evaluates to P6DT16H34M59.613999S, which is the same as the right operand for the eq operator above. A bit of a tricky bug I'd say. Frans ```

 Re: [saxon] xs:dateTime, plus sign is not permitted From: Frans Englich - 2006-02-07 18:11 ```On Tuesday 24 January 2006 12:14, Frans Englich wrote: > Hi, > > I think I've found a bug in the handling of lexical representations of > xs:dateTime. The following expression compiles: The expression: xdt:dayTimeDuration("P3DT4H3M3.100S") div xs:double("NaN") Should result in an error, because "If \$arg2 is NaN an error is raised [err:FOCA0005]". xdt:yearMonthDuration behaves fine though. It's weird that XQTS doesn't have a tests for this. Frans ```

 Re: [saxon] xs:dateTime, plus sign is not permitted From: Frans Englich - 2006-02-07 18:49 ```On Tuesday 24 January 2006 12:14, Frans Englich wrote: > Hi, > > I think I've found a bug in the handling of lexical representations of > xs:dateTime. The following expression compiles: xdt:yearMonthDuration("P3Y36M") div xs:double("INF") xdt:yearMonthDuration("P3Y36M") div xs:double("-INF") xdt:dayTimeDuration("P3D") div xs:double("INF") xdt:dayTimeDuration("P3D") div xs:double("-INF") All evaluates to P0M and PT0S, respectively. The descriptions for op:multiply-dayTimeDuration and=20 op:multiply-yearMonthDuration reads: If \$arg2 is positive or negative infinity, the result overflows and is hand= led=20 as discussed in 10.1.1 Limits and Precision. 10.1.1 Limits and Precision reads: If a processor limits the number of digits allowed in the representation of= =20 xs:integer and xs:decimal then overflow and underflow situations can arise= =20 when it tries to execute the functions in 10.6 Arithmetic Functions on=20 Durations. In these situations the processor =B7must=B7 return zero in case= of=20 numeric underflow and P0M or PT0S in case of duration underflow. It =B7must= =B7=20 raise an error [err:FODT0002] in case of overflow. My conclusion is that for all the above expressions should FODT0002 be rais= ed=20 because overflows happens(for duration underflow P0M/PT0S is in order). Am = I=20 seeing this the right way? Frans ```

 Re: [saxon] xs:dateTime, plus sign is not permitted From: Frans Englich - 2006-02-07 21:26 ```On Tuesday 07 February 2006 16:39, Frans Englich wrote: > On Tuesday 24 January 2006 12:14, Frans Englich wrote: > > Hi, > > > > I think I've found a bug in the handling of lexical representations of > > xs:dateTime. The following expression compiles: > > xdt:yearMonthDuration("P3Y36M") div xs:double("INF") > xdt:yearMonthDuration("P3Y36M") div xs:double("-INF") > xdt:dayTimeDuration("P3D") div xs:double("INF") > xdt:dayTimeDuration("P3D") div xs:double("-INF") > > All evaluates to P0M and PT0S, respectively. > > The descriptions for op:multiply-dayTimeDuration and > op:multiply-yearMonthDuration reads: The expressions above are incorrect; the * operator should be used, not div. The above expressions, after having changed the operator, seems to evaluate to the empty sequence. (It wouldn't surprise me if it is possible to provoke a crash, since I doubt the static type of the arithemtic expression has a cardinality that expresses the empty sequence as one of its possibilities.) Frans ```

 RE: [saxon] xs:dateTime, plus sign is not permitted From: Michael Kay - 2006-02-08 09:29 ```> The following expression evaluates to false, while I think it > should evaluate > to true: > > xdt:dayTimeDuration("P3DT4H3M3.100S") + > xdt:dayTimeDuration("P3DT12H31M56.514S") > eq xdt:dayTimeDuration("P6DT16H34M59.613999S") > > > The expression(taken from above): > > xdt:dayTimeDuration("P3DT4H3M3.100S") + > xdt:dayTimeDuration("P3DT12H31M56.514S") > > evaluates to P6DT16H34M59.613999S, which is the same as the > right operand for > the eq operator above. Clearly "false" is the right answer for the first expression, but P6DT16H34M59.613999S is the wrong answer for the second expression. This comes out correctly in my current build. Comparing the code, it seems the small error in 8.6.1 was not caused by imprecise addition, but by a rounding error when converting the result of the addition to a string (the conversion is implemented using double arithmetic). In other words, the result of the addition is actually P6DT16H34M59.614S, but it is not displayed accurately. This inaccurate conversion does not occur in your first expression where you compare the result of the addition to a constant. Michael Kay http://www.saxonica.com/ ```

 RE: [saxon] xs:dateTime, plus sign is not permitted From: Michael Kay - 2006-02-08 13:34 ```> xdt:dayTimeDuration("P3DT4H3M3.100S") div xs:double("NaN") > > Should result in an error, because "If \$arg2 is NaN an error > is raised > [err:FOCA0005]". xdt:yearMonthDuration behaves fine though. > > It's weird that XQTS doesn't have a tests for this. This one is OK in the current build - I think Carmelo reported it while developing the next batch of XQTS tests. You two seem to be chasing the same hares... By the way, it would help if distinct problems had distinct subject titles. Michael Kay http://www.saxonica.com/ ```

 RE: [saxon] xs:dateTime, plus sign is not permitted From: Michael Kay - 2006-02-08 13:39 ```I can't reproduce this one: Saxon 8.6.1 from Saxonica Java version 1.5.0_06 Compiling query from {xdt:yearMonthDuration('P3Y36M') * xs:double('INF') } Compilation time: 630 milliseconds Error on line 1 of *module with no systemId*: FODT0002: Overflow when multiplying/dividing a duration by a number Query processing failed: Run-time errors were reported For division, I believe a zero-length duration is the correct answer. Michael Kay http://www.saxonica.com/ > -----Original Message----- > From: saxon-help-admin@... > [mailto:saxon-help-admin@...] On Behalf Of > Frans Englich > Sent: 07 February 2006 20:37 > To: saxon-help@... > Subject: Re: [saxon] xs:dateTime, plus sign is not permitted > > On Tuesday 07 February 2006 16:39, Frans Englich wrote: > > On Tuesday 24 January 2006 12:14, Frans Englich wrote: > > > Hi, > > > > > > I think I've found a bug in the handling of lexical > representations of > > > xs:dateTime. The following expression compiles: > > > > xdt:yearMonthDuration("P3Y36M") div xs:double("INF") > > xdt:yearMonthDuration("P3Y36M") div xs:double("-INF") > > xdt:dayTimeDuration("P3D") div xs:double("INF") > > xdt:dayTimeDuration("P3D") div xs:double("-INF") > > > > All evaluates to P0M and PT0S, respectively. > > > > The descriptions for op:multiply-dayTimeDuration and > > op:multiply-yearMonthDuration reads: > > The expressions above are incorrect; the * operator should be > used, not div. > The above expressions, after having changed the operator, > seems to evaluate > to the empty sequence. > > (It wouldn't surprise me if it is possible to provoke a > crash, since I doubt > the static type of the arithemtic expression has a > cardinality that expresses > the empty sequence as one of its possibilities.) > > > Frans > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep > through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. > DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&; > dat=121642 > _______________________________________________ > saxon-help mailing list > saxon-help@... > https://lists.sourceforge.net/lists/listinfo/saxon-help > ```

 Re: [saxon] xs:dateTime, plus sign is not permitted From: Frans Englich - 2006-02-09 01:02 ```On Wednesday 08 February 2006 13:39, Michael Kay wrote: > I can't reproduce this one: Neither can I, today.. I am quite confident I saw that empty sequence from a similar expression, I just can't recall exactly which one. One thing is certain though: I evidently was a bit dizzy when posting those cases. Frans ```

 Re: [saxon] xs:dateTime, plus sign is not permitted From: Frans Englich - 2006-02-09 14:47 ```On Wednesday 08 February 2006 09:29, Michael Kay wrote: > > The following expression evaluates to false, while I think it > > should evaluate > > to true: > > > > xdt:dayTimeDuration("P3DT4H3M3.100S") + > > xdt:dayTimeDuration("P3DT12H31M56.514S") > > eq xdt:dayTimeDuration("P6DT16H34M59.613999S") > > > > > > The expression(taken from above): > > > > xdt:dayTimeDuration("P3DT4H3M3.100S") + > > xdt:dayTimeDuration("P3DT12H31M56.514S") > > > > evaluates to P6DT16H34M59.613999S, which is the same as the > > right operand for > > the eq operator above. > > Clearly "false" is the right answer for the first expression, but > P6DT16H34M59.613999S is the wrong answer for the second expression. > > This comes out correctly in my current build. Comparing the code, it seems > the small error in 8.6.1 was not caused by imprecise addition, but by a > rounding error when converting the result of the addition to a string (the > conversion is implemented using double arithmetic). In other words, the > result of the addition is actually P6DT16H34M59.614S, but it is not > displayed accurately. This inaccurate conversion does not occur in your > first expression where you compare the result of the addition to a > constant. I probably stumbled on the same case again. I *think* this expression should evaluate to true: (xs:time("08:12:32") - xs:time("13:13:32")) eq xdt:dayTimeDuration("-PT5H1M") (Perhaps it's only the seconds component that's implemented with double arithmetic, better mention it.) Cheers, Frans ```