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.