21222 2013-03-08 14:06:31 +0000 Tests that depend on a fixed timezone (UTC) 2013-07-04 13:46:39 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3 & XPath 3 Test Suite Candidate Recommendation PC Windows NT CLOSED FIXED P2 normal --- 1 christian.gruen oneil mike tim public-qt-comments oldest_to_newest 84119 0 christian.gruen 2013-03-08 14:06:31 +0000 A number of tests in the QT3TS seem to depend on a fixed timezone (UTC). Below, I have listed the names of the tests along with a) the expected results of the test suite, and b) the results I would expect for time zone +01:00: - cbcl-gDay-equal-019 : false; true - cbcl-gDay-equal-020 : false; true - cbcl-gMonthDay-equal-019 : false; true - cbcl-gMonthDay-equal-020 : false; true - cbcl-subtract-dates-003 : P2192DT1H; P2192D - cbcl-subtract-dates-004 : -P2192DT1H; -P2192D - cbcl-subtract-dateTimes-003 : P2192DT1H; P2192D - cbcl-subtract-dateTimes-004 : -P2192DT1H; -P2192D - cbcl-subtract-times-001 : -PT1H; PT0S - cbcl-subtract-times-002 : PT1H; PT0S - cbcl-subtract-times-003 : PT9H; PT8H - cbcl-subtract-times-004 : -PT9H; -PT8H - cbcl-time-equal-019 : false; true - cbcl-time-greater-than-004 : false; true - cbcl-time-greater-than-005 : true; false - cbcl-time-greater-than-009 : true; false - cbcl-time-greater-than-010 : false; true - cbcl-time-less-than-004 : true; false - cbcl-time-less-than-005 : false; true - cbcl-time-less-than-009 : false; true - cbcl-time-less-than-010 : true; false 84412 1 tim 2013-03-14 13:34:06 +0000 I'd like to resolve these with a feature dependency. I suggest adding "implicit-timezone" to dependencyEnumType, and using <dependency type="implicit-timezone" value="PT0S"/> on the tests. If O'Neil agrees and updates the schema, I'll make the change to the affected tests. 84419 2 mike 2013-03-14 14:39:37 +0000 That's tricky because implicit-timezone() is required to be consistent with current-dateTime(), therefore implementations might not be able to set it independently. And they certainly might have difficulty setting it to different values in the course of a single test run (because it might require changing the system clock). Also, since we've called for test results, I don't particular want to make people change their test drivers at this juncture. I would prefer a solution that eliminates the dependency, e.g. change cbcl-gDay-equal-019 to xs:gDay("---31+00:15") eq xs:gDay("---31") (we can safely assume that no-one is running with implicit timezone = +00:15, even though it is legal) Similarly change cbcl-subtract-dates-003 to xs:date("2008-12-31") - xs:date("2002-12-31+01:00") - implicit-timezone() 84481 3 tim 2013-03-15 16:48:23 +0000 A fix has been attempted for - cbcl-gDay-equal-019 - cbcl-gDay-equal-020 - cbcl-gMonthDay-equal-019 - cbcl-gMonthDay-equal-020 - cbcl-subtract-dates-003 - cbcl-subtract-dates-004 - cbcl-subtract-dateTimes-003 - cbcl-subtract-dateTimes-004 - cbcl-subtract-times-001 - cbcl-subtract-times-002 - cbcl-subtract-times-003 - cbcl-subtract-times-004 - cbcl-time-equal-019 and some other similar tests. Please confirm that the fixes work. Suggestions are welcome to resolve the problems with - cbcl-time-greater-than-004 - cbcl-time-greater-than-005 - cbcl-time-greater-than-009 - cbcl-time-greater-than-010 - cbcl-time-less-than-004 - cbcl-time-less-than-005 - cbcl-time-less-than-009 - cbcl-time-less-than-010 84483 4 christian.gruen 2013-03-15 19:21:02 +0000 The fixes for the following tests look perfect to me: - cbcl-gMonthDay-equal-019 - cbcl-gMonthDay-equal-020 - cbcl-subtract-dates-003 - cbcl-subtract-dates-004 - cbcl-subtract-dateTimes-003 - cbcl-subtract-dateTimes-004 - cbcl-subtract-times-001 - cbcl-subtract-times-002 - cbcl-subtract-times-003 - cbcl-subtract-times-004 I’m not sure about the following ones, though: - cbcl-gDay-equal-019 - cbcl-gDay-equal-020 - cbcl-time-equal-019 As I assume that the timezone check (+PT1M) will never be true, I guess that the second branch will be chosen in all cases, which always gives me "false" in my timezone. The following query should yield "true" everywhere on this globe: xs:gDay("---31+00:01") ne xs:gDay("---31") > Suggestions are welcome to resolve the problems with > > - cbcl-time-greater-than-004 > ... These queries could as well be resolved with artificial timezones, such as... xs:time("00:00:00+00:01") gt xs:time("00:00:00") 84551 5 tim 2013-03-18 09:33:36 +0000 (In reply to comment #4) > The fixes for the following tests look perfect to me: > I’m not sure about the following ones, though: > > - cbcl-gDay-equal-019 > - cbcl-gDay-equal-020 > - cbcl-time-equal-019 That was an unintentional typo - now fixed. Please confirm that you are happy with the change. 84552 6 christian.gruen 2013-03-18 09:49:44 +0000 I am happy! Thanks. 84556 7 tim 2013-03-18 11:01:36 +0000 The tests: - cbcl-time-greater-than-004 - cbcl-time-greater-than-005 - cbcl-time-greater-than-009 - cbcl-time-greater-than-010 - cbcl-time-less-than-004 - cbcl-time-less-than-005 - cbcl-time-less-than-009 - cbcl-time-less-than-010 are now fixed - hopefully in a timezone independent manner. Please mark as CLOSED if you agree with the resolution. Otherwise, REOPEN. 84926 8 christian.gruen 2013-03-25 16:20:19 +0000 The following test also depends on the current timezone: Name: cbcl-distinct-values-003 Query: distinct-values(( xs:dateTime("2008-01-01T13:00:00"), xs:dateTime("2008-01-01T13:00:00+00:00") )) Currently expected result: one item Returned result: one or two items Once again, we could use a non-existing time zone and expect two items as result: distinct-values(( xs:dateTime("2008-01-01T13:00:00+00:00"), xs:dateTime("2008-01-01T13:00:00+00:01") )) 85110 9 tim 2013-03-28 17:31:48 +0000 I've attempted a fix. Please mark as CLOSED if you agree with the resolution. Otherwise, REOPEN. 89895 10 christian.gruen 2013-06-26 13:54:32 +0000 "cbcl-hash-join-3" is another (and presumably the last) test case that depends on UTC as fixed timezone: for $x in (xs:date("2010-10-10"), xs:date("1997-01-01+12:00"), xs:date("1997-01-02+12:00")) for $y in (xs:date("2010-10-10Z"), xs:date("2010-10-10+01:00"), xs:date("1997-01-01-12:00")) where $x = $y return $x In essence, xs:date("2010-10-10") = xs:date("2010-10-10+01:00") returns false for most timezones. The test case could also be rewritten by removing the implicit timezone, or an alternative result could be added ("1997-01-02+12:00"). 90349 11 tim 2013-07-04 12:43:12 +0000 Fixed. Please mark as CLOSED if you agree with the resolution. Otherwise, REOPEN. 90350 12 christian.gruen 2013-07-04 13:46:39 +0000 Thanks.