This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25375 - [xslt 3.0] Maps and the implicit timezone
Summary: [xslt 3.0] Maps and the implicit timezone
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-17 10:09 UTC by Michael Kay
Modified: 2015-10-29 09:50 UTC (History)
2 users (show)

See Also:


Attachments

Description Michael Kay 2014-04-17 10:09:12 UTC
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.
Comment 1 Michael Kay 2014-04-17 11:30:31 UTC
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.
Comment 2 Sharon Adler 2014-07-17 14:45:28 UTC
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.
Comment 3 Jonathan Robie 2014-07-29 09:04:31 UTC
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.
Comment 4 Michael Kay 2014-08-01 19:58:52 UTC
The XSLT 3.0 spec has been updated to apply this rule. (Work remains to be done on the 3.1 specifications).
Comment 5 Michael Kay 2015-06-09 22:34:33 UTC
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.