This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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.
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()
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
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")
(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.
I am happy! Thanks.
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.
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") ))
I've attempted a fix. Please mark as CLOSED if you agree with the resolution. Otherwise, REOPEN.
"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").
Fixed. Please mark as CLOSED if you agree with the resolution. Otherwise, REOPEN.
Thanks.