Uploaded image for project: 'Specification'
  1. SPEC-215

Merge DV_PARTIAL_XX date/time classes and move ISO 8601 semantics to Support IM

    Details

    • Change Description:
      Hide
      Changes made:
      - Remove the DV_PARTIAL_DATE, DV_PARTIAL_TIME, DV_PARTIAL_DATE_TIME classes
      - move the functionality into the corresponding DV_DATE, etc classes
      - reverse the sense of the xxx_unknown flags in the classes, so that they
        indicate the "xxx_unknown" (e.g. month_unknown) etc states rather than
        xxx_known states of the parts of dates and times.
      - move the ISO 8601 semantics to a set of classes in teh support IM, and inherit
        these classes into the corresponding DV_XX classes. This cleanly separates the
        ISO 8601 semantics from the openEHR semantics, making it clearer for
        implementers, as well as making the ISO 8601 semantics accessible elsewhere in
        the openEHR models.
      Show
      Changes made: - Remove the DV_PARTIAL_DATE, DV_PARTIAL_TIME, DV_PARTIAL_DATE_TIME classes - move the functionality into the corresponding DV_DATE, etc classes - reverse the sense of the xxx_unknown flags in the classes, so that they   indicate the "xxx_unknown" (e.g. month_unknown) etc states rather than   xxx_known states of the parts of dates and times. - move the ISO 8601 semantics to a set of classes in teh support IM, and inherit   these classes into the corresponding DV_XX classes. This cleanly separates the   ISO 8601 semantics from the openEHR semantics, making it clearer for   implementers, as well as making the ISO 8601 semantics accessible elsewhere in   the openEHR models.
    • Approved By:
      ARB

      Description

      The current definition of the date/time data types include 7 classes,
      providing the following functionality:
      - Date
      - Time
      - Date_time
      - Duration
      - partial forms of the first 3 of these
      Since openEHR is now aiming to be 100% compatible with ISO8601,
      we should merge the partial types into the non-partial types
      making 4 classes, corresponding directly to the 4 types of
      ISO8601 and their functionality. This will also simplify
      implementation, since the representation of the openEHR date/time
      classes is already an ISO8601 string; and also because implementers
      will use external libraries such as joda that implement ISO8601 in
      a fairly faithful way.

      A related issue is that all ISO8601 date/time types are in teh Gregorian
      calendar, and there may be a need to accommodate date/times from other
      calendars somewhere in the health record, e.g. where Islamic date/times
      are mentioned with respect to festivals, eating etc.

        Attachments

          Activity

            People

            • Assignee:
              OLDthomasbeale OLDthomasbeale
              Reporter:
              OLDthomasbeale OLDthomasbeale
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: