search

arrowhead-f / core-rfcs

RFCs and PRE-RFCs for proposing significant changes to or the creation of new core systems and services.
Eclipse Public License 2.0
0 stars 0 forks source link

Timestamps, ISO8601 and IDDs #1

Open emanuelpalm opened 4 years ago

emanuelpalm commented 4 years ago

The 4.1.3 version of the mandatory core services uses a date/time format that does not strictly adhere to any popular standard for machine-readable timestamp. While Arrowhead should not force the use of any one particular date/time format, we make it more convenient for users of the core services and systems if we are consistent about what formats we use.

I propose that:

  1. Only ISO8601 strings on the form yyyy-mm-ddThh:ii:ss(.z{1,9})?Z be used for timestamps by the Service Registry, Authorization System, Orchestrator and the other core systems. An example of a compliant timestamps would be 2020-06-17T11:18:23.143Z. Note that the ending Z indicates that the timezone is UTC. Also, the number of decimals after the second part could be allowed to vary between 1 and 9. If zero subsecond decimals are used, the dot (.) must be omitted.
  2. The IDD of every core service that has at least one interface/function serving data objects containing timestamps should explicitly document that the ISO8601 date/time format is used, that the UTC timezone is always used, and that any number of subsecond decimals of between 0 and 9 digits may be used.

The advantages of these changes are:

  1. Decreases implementation burden for service integration by consistently using the same format.
  2. Improves room for code generation by being explicit about how date/time strings are formatted in IDDs.

The disadvantages of these changes are:

  1. Breaks compatibility with systems that rely on the existing date/time format.

Unresolved and related issues are:

A. There should exist some default way of documenting what date/time format a particular IDD uses. Could something like a Communication Profile (CP) be created for ISO8601 timestamps? The existence of such a CP could also make it easier to model service data objects, as the modeller would only have to refer to whatever "data types" (date/time formats) are defined by the CP.

emanuelpalm commented 4 years ago

This PRE-RFC is based on the issue raised here: https://github.com/arrowhead-f/core-java-spring/issues/193.