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.