Executive summary

I believe the last example for the is() built-in function of DMNv1.3 is wrong.

Details

The example from DMNv1.3 which I believe is wrong is:
is(time("23:00:50z"), time("23:00:50+00:00”)) is false

Besides that is not FEEL and not consistent with the other examples, but likely it is meant to be humanly interpreted as is(time("23:00:50z"), time("23:00:50+00:00”)) = false which I argue is wrong semantically.

Accordingly to 10.3.2.3.4 time:

A time in the semantic domain is a value of the XML Schema time datatype. It can be represented by a sequence of numbers for the hour, minute, second, and an optional time offset from Universal Coordinated Time (UTC).

Understanding from this first sentence is that in the FEEL semantic domain time is defined by time: H, M, S, OFFSET?

it continues with:

If a time offset is specified, including time offset = 00:00, the time value has a UTC form and is comparable to all time values that have UTC forms.
If no time offset is specified, the time is interpreted as a local time of day at some location,

So we can have in the FEEL semantic domain a

• time: H, M, S, no offset specified "local time of day at some location"
  or
• time: H, M, S, OFFSET

This is consistent with 10.3.4.1 Conversion functions:

time string – either
a string value in the lexical space of the time datatype specified by XML Schema Part 2 Datatypes; or
a string value that is the extended form of a local time representation as specified by ISO 8601, followed by the character "@", followed by a string value that is a time zone identifier in the IANA Time Zones Database (http://www.iana.org/time-zones)

Therefore:
if we are in the first case by XML Schema Part 2 Datatypes we will have an offset if something follow the ":ss" seconds part in the string,
otherwise,
if we use the second case "hh:mm:ss@location" form, we will not have an XML Schema Part 2 Datatypes offset, but we will interpret the time at some geographical location offset based on IANA.

Follows interpretation of a few examples of time strings, and their FEEL semantic domain projection:

Accordingly to DMNv1.3 they will be all equals as in a=b (as valuet() does return the same for all of them).

Accordingly to DMNv1.3 they are all FEEL semantically domain different expect the last two, because once projected to the semantic domain they represent the same hour, minute, second, AND offset quantity, accordingly to a string value in the lexical space of the time datatype specified by XML Schema Part 2 Datatypes.

Hence, resulting in

is(time("23:00:50z"), time("23:00:50+00:00")) = true

instead.

Proposal

change last line example from:

is(time("23:00:50z"), time("23:00:50+00:00”)) is false

to

is(time("23:00:50z"), time("23:00:50+00:00")) = true

Correct table 77

change last line example from:

is(time("23:00:50z"), time("23:00:50+00:00”)) is false

to

is(time("23:00:50z"), time("23:00:50+00:00")) is true