W3C home > Mailing lists > Public > public-qt-comments@w3.org > April 2014

[Bug 25375] New: [xslt 3.0] Maps and the implicit timezone

From: <bugzilla@jessica.w3.org>
Date: Thu, 17 Apr 2014 10:09:12 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-25375-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25375

            Bug ID: 25375
           Summary: [xslt 3.0] Maps and the implicit timezone
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

We say that two keys (in a map) are "the same key" if deep-equal(K1, K2, $UCC)
holds, where $UCC is the Unicode codepoint collation. We have therefore tried
to make the definition context-independent as far as collations are concerned.
However, deep-equal() still has a dependency on the dynamic context when it
comes to comparisons of date/time values with no explicit timezone.

The effect is that maps as currently defined cannot "cross timezone
boundaries"; a map that is perfectly OK in one (implicit) timezone may become
invalid, because of duplicate keys, when used in a dynamic context with a
different implicit timezone.

The complications become worse when maps are treated as functions, because we
now get all the issues concerned with higher-order functions that carry context
information in their closure.

Possible solutions:

(A) disallow maps from containing (as keys) date/time values with no timezone.
This can be done in several ways:

(A.1) using a timezoneless date/time value as a key is an error

(A.2) a timezoneless date/time value is converted to a value with timezone
using the implicit timezone at the point where the entry is added to the map.

(A.3) a timezoneless date/time value is converted to a value with timezone by
assuming UTC.

(B) treat values-with-timezone as being always not-equal to
values-without-timezone. The disadvantage of this is that it introduces yet
another equality operator to the system, and people would want other ways of
making use of this flavour of equality matching.

The least disruptive solution is probably A.2. But I would prefer a solution in
which map:get() is deterministic and context-independent, so that you never get
the situation where map:get() may or may not find something depending on the
context. I'm therefore going to propose A.3. Essentially, functions that accept
a key value (such as map:get() and map:new()) treat any timezoneless date/time
as being UTC; functions that return keys (such as map:keys()) always return
dates/times with a timezone.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 17 April 2014 10:09:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:46 UTC