ISO time offset not supported

[SimonCockx]

In our effort to support the ISO 20022 schema, we have found a slight mismatch with Rosetta in the way that a time in a day is specified. In short, the ISO schema allows an optional UTC offset to be specified (e.g., 12:34:00+02:00), whereas the DSL time type only supports local times without an offset, and the CDM uses the principle of business centres and timezones to achieve a similar (but not quite the same) offset behaviour. This issue intents to stimulate discussion on potential solutions to breach this gap.

Context

The ISO auth.030.001.03 schema defines the ISOTime type as a synonym of the xs:time type. The documentation mentions the following:

A particular point in the progression of time in a calendar day expressed in either UTC time format (hh:mm:ss.sssZ), local time with UTC offset format (hh:mm:ss.sss+/-hh:mm), or local time format (hh:mm:ss.sss). These representations are defined in "XML Schema Part 2: Datatypes Second Edition - W3C Recommendation 28 October 2004" which is aligned with ISO 8601.
Note on the time format:

1. beginning / end of calendar day
   00:00:00 = the beginning of a calendar day
   24:00:00 = the end of a calendar day
2. fractions of second in time format
   Decimal fractions of seconds may be included. In this case, the involved parties shall agree on the maximum number of digits that are allowed.

The issue arises when testing our ISO 20022 support with a deserialisation/serialisation roundtrip, i.e.,

XML ISO document   -->   Rosetta Java object   -->   XML ISO document

Right now, we loose information about UTC offset. Here are examples where the roundtrip fails:

12:34:00+02:00   -->   10:34:00   -->   10:34:00

12:34:00Z   -->   12:34:00   -->   12:34:00

We need a solution to fully support the ISO standard.

Why simply adding UTC offset information in our time type might not be a good idea

Distinguishing between a local time and a time with an offset, the CDM currently uses the following pattern:

• a local times is represented as a value of type time,
• a time with an offset is represented as a value of type time accompanied with a BusinessCentreEnum or a string indicating the timezone.

In contrast, the ISO time format joins local time and time with an offset into one, i.e.,

• if no time offset indicator is present, it is a local time,
• else it is a time with an offset as indicated.

There are two reasons why the CDM's pattern is superior.

1. The CDM benefits from additional type safety, since it distinguishes between local times and time with an offset on the type level.
2. As the Wikipedia page on the ISO time format rightfully mentions, just having a UTC offset is not enough to fully specify a time for regions that have daylight saving time.

Discussion is needed

To properly breach this gap, additional analysis is required on the exact usage of the ISOTime type. Guiding questions:

• How does ISO handle regions with daylight saving time?
• Is there a semantic difference between reporting 12:34:00Z versus reporting 12:34:00?