Date/Time modelling problem

Owned by Thomas Beale
Last updated: 26-Aug-2018
3 min read

Requirements

There are three basic requirements we have with respect to dates, times and duration:

  • we need some types that stand for primitive Date, Time, DateTime and Duration so that higher types can refer to them (in a similar way that other types use String, Integer etc), in particular:
    • DV_DATE, DV_TIME, DV_DATE_TIME, DV_DATE_TIME
    • the AOM2 types C_DATE, ...
    • various usages of dates and times in the TP spec
    • GDL spec
  • We need the semantics of partial dates, times and durations, long established in health and in openEHR - for which we follow ISO8601 semantics
  • the serial forms should be ISO8601, i.e. also the same as in XML, JSON etc.

Current situation

In most places, the above classes refer to types ISO8601_DATE, etc (now slightly renamed to Iso8601_date etc), which were defined as interface-only classes to be inherited. In AOM2, the C_DATE etc classes referred to 'Date', etc.

DV_DATE, DV_TIME etc supplied their own value: String field, which is formatted according to the ISO8601 standard. So the model of DV_DATE etc is not quite right - they inherit from ISO8601 but supply their own String field.

Separately, the various programming languages have very varied ideas of 'Date', 'Time', 'Duration' etc.

To date, we have two areas of legacy that I can see:

  • in native implementations (Java, C#, PHP etc), Date.value is a String field, and Date inherits from a class ISO8601_DATE, which provides the semantics for that field
  • in actual EHR DBs, Date.value, Duration.value data will be everywhere
    • and XML docs based on the openEHR XSD will have ISO8601 String fields inside the Date/time types.

Proposals

Original Proposal (TB)

See original email: essentially:

  • move the ISO8601_DATE etc classes to Foundation Types spec
    • rename ISO8601_DATE etc to Iso8601_date, to be consistent with capitalisation of primitive type-names (like 'String', 'Integer' etc)
    • put the value:String field in these types (seems obvious: ISO8601 is after a String-based concept)
    • add notional Date and IDate classes to show that there are native date/time types, and that there is some assumed common interface of Date and Iso8601_date etc
  • retain the inheritance into DV_DATE etc, but remove DV_DATE.value, since now it would be inherited
  • change AOM2 C_DATE to refer to Iso8601_date etc, not 'Date'

Proposal (Bjorn +/- Pablo)

Bjorn:

  • Remove the ISO8601_date class
  • Move the Date.value into the Temporal class
  • Remove the Date class
  • Rename IDate to Date

This would result in just one set of primitive types Date, Time, Date_time and Duration, which I agree would be nicer. My understanding is that you are saying that Date.value, which is a native value - will be different in Java, C#, Python etc - is the value field of Date (via Temporal). But maybe you are saying that this is actually the String field, i.e. the field that we already use.

If that is the case, this is really just saying that what is called Iso8601_date in the other models (RM, AOM, TP) should be renamed to 'Date', and that in the Foundation types, we should collapse the triple types IDate/Date/Iso8601_date to just 'Date', which has a single value: String field inherited from Temporal. (confirmed by Bjørn Næss @ DIPS)

Response by TB

If the above is true,  I like it, it is nice and simple, but:

  • it makes it look as if there are primitive types like Date, Time, Date_time, Duration, which have ISO8601 semantics and a String field, in programming language environments. This is not literally true, but we can of course document that these Date etc classes are 'openEHR's assumed version of Date, and you have to work out how to connect it to your real built-in types, like Timestamp, or Instant or whatever'
  • we must ensure that the result does not change the current value field which is a String, since that is already in the field
  • I would want to hear from all implementers to make sure they are ok with this.

Pablo had a few other things to say, I think we will discuss some separately (AOM2 fix for example).

Final Proposal

Collapse each set of class triples (i.e. IDate, Date and Iso8601_date etc) into just a single class named Date, etc, that has a String field and all the interface of IDate + Iso8601_date and so on.

Responses by Back-end Implementers

  • Code 24:
  • DIPS:
  • EHRServer:
  • EtherCIS:
  • Marand:
  • Ocean: