25375 2014-04-17 10:09:12 +0000 [xslt 3.0] Maps and the implicit timezone 2015-10-29 09:50:34 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Last Call drafts PC All CLOSED FIXED P2 normal --- 1 mike mike jonathan.robie sca.w3c public-qt-comments oldest_to_newest 104024 0 mike 2014-04-17 10:09:12 +0000 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. 104029 1 mike 2014-04-17 11:30:31 +0000 Another little consequence of this problem: we say that in a MapExpr it's a static error if two keys are the same, but we cannot determine whether two keys are the same until we know the implicit timezone, and this is part of the dynamic context. 109057 2 sca.w3c 2014-07-17 14:45:28 +0000 This bug needs to be discussed in the context of the Joint meeting. MKay sent note to Joint chairs requesting that this bug be put on the Agenda for the Joint F2F in Hursley. 109472 3 jonathan.robie 2014-07-29 09:04:31 +0000 The Working Group decided to resolve this bug as follows: You can't mix dates/times with timezones and dates/times without timezones in the same map - an error [err:DONTDOTHAT] is raised if an attempt is made to add a key that does not obey this rule. For equality matching, the implicit timezone is used, per the current language specification. 109764 4 mike 2014-08-01 19:58:52 +0000 The XSLT 3.0 spec has been updated to apply this rule. (Work remains to be done on the 3.1 specifications). 120860 5 mike 2015-06-09 22:34:33 +0000 Subsequently to this decision, bug #28632 was raised, and the decision on that bug overturned this decision. The effect is that option (B) has been adopted.