fo-test-fn-adjust-time-to-timezone-002 in app/fo-spec-examples.xml is timezone dependent?

[faassen]

This test:

   <test-case name="fo-test-fn-adjust-time-to-timezone-002">
      <description>Test case for fn:adjust-time-to-timezone</description>
      <created by="Michael Kay using generate-qt3-test-set.xsl" on="2017-03-16"/>
      <environment ref="global"/>
      <test>
        fn:adjust-time-to-timezone(xs:time("10:00:00-07:00"))
      </test>
      <result>
         <assert-deep-eq>xs:time("12:00:00-05:00")</assert-deep-eq>
      </result>
   </test-case>

appears to be dependent on the timezone in which the test is being run, as adjust-time-to-timezone says to use the implicit timezone in the context at that point.

Is there something in the test suite that sets the implicit timezone in which the tests should be run? The tests in fn/implicit-timezone.xml appear to be carefully written to avoid actually testing against the timezone itself.

[michaelhkay]

First, note that this test set is automatically generated from examples in the spec, which means there is limited scope to set custom dependencies. The text of the examples in the spec says "Assume the dynamic context provides an implicit timezone of -05:00 (-PT5H0M).".

That raises the question of why the test is succeeding in Saxon. It turns out that we are not actually returning the value 12:00:00-05:00, but rather (since I am now in timezone +01:00) the value 18:00:00+01:00, which is good enough to satisfy the "deep-equal" test against the expected result. Adjusting the timezone alters the timezone offset, but this has no effect on a deep-equal test.

If this were a hand-written test then I would be happy to change it to be more precise, but writing tests that work both as spec examples and as conformance tests is often tricky.

[faassen]

It would be nice if the test runner had a way to set the implicit timezone so that this could be precisely controlled. I'm left to wonder why this test failed for one user in Xee (I haven't had it fail for me nor in the github actions which presumably have a different timezone). We'll dig deeper!

[faassen]

I think the problem with this test is as follows:

If you're in an implicit timezone where fn:adjust-time-to-timezone(xs:time("10:00:00-07:00")) makes the time cross midnight, that information is lost.

If you to compare the times you place them in the same date, there's no way that function knows that one time has actually crossed midnight. So therefore the comparison will fail.

So this test is not robust with timezones ahead enough of -07:00 so that the time falls in the next day. For instance, in a +08:00 timezone this time will be 01:00 the next day.