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

Description of DateTime unclear (e.g. precision)



    • 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.

      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


      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.





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