Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-32883

Description of DateTime unclear (e.g. precision)

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • R4
    • Modeling & Methodology
    • Datatypes
    • Hide

      We will update the description to indicate that milliseconds are optionally allowed for the time part of the dateTime.

      Show
      We will update the description to indicate that milliseconds are optionally allowed for the time part of the dateTime.
    • Ron Shapiro / Lloyd McKenzie: 4-0-0
    • Clarification
    • Non-substantive
    • R5

    Description

      This tickets asks for an improvement in the description of the DateTime (and, by extension, Time) primitive data type, in particular with regard to the precisions of individual elements.

      The current description says the following about the general format:

      "The format is YYYY, YYYY-MM, YYYY-MM-DD or YYYY-MM-DDThh:mm:ss+zz:zz, e.g. 2018, 1973-06, 1905-08-23, 2015-02-07T13:28:17-05:00 or 2017-01-01T00:00:00.000Z."

      Reading this, I assumed 

      1. That in the given format patterns ("YYYY",  "YYYY-MM-DDThh:mm:ss+zz:zz") were such that each character is suppose to represent exactly one digit.
      2. That the list of format patterns was complete, e.g. represented all allowed patterns.

      On this reading, only whole-second-level precision should be allowed. However, as per this Zulip thread, the DateTime supports an arbitrary level of second precision. This is also indicated by the given regular expression. However, below the table to primitive data types precision, it is explicitly stated that there are issues with the regular expression and that they are not to be taken as normative. I know of other people who have been confused by this description (see also the linked thread). 

      I therefore request that the descriptions of the DateTime and Time be updated to more clearly list the allowed format and the precision of the individual parts. In particular, this description should be complete without having to read the regular expression (alternatively, the RegExp could be refined and made normative). Insofar as the definition reflects a definition that is thoroughly described in another standard (eg. XML), this deeper definition could simply be linked.

      Given that this is a primitive used throughout the standard and will be used by many implementers, I suggest any change decided upon should also be added to any upcoming R4 technical correction.

       

      Attachments

        Activity

          People

            marc.duteau Marc Duteau
            morten Morten Ernebjerg
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: