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

Define parameters of dateOp

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • R4
    • FHIR Infrastructure
    • Mapping Language
    • Hide

      Will define separate operations for each target type - i.e. toDate, toTime, toDateTime, etc., each with a single argument conveying the syntax.  Will not add timezone as an argument because it can be injected into the variable on which the operation is being called.  E.g.

      foo = "82/11/09 5:15"

      foo2 = foo + "-04:00"

      foo2.toDateTime('yy/11/09 h:mmZZ') = "1982-11-09T05:15:00:00-04:00"

      Have agreed to use the Java syntax for the argument to the above functions, but will prohibit use of those features that don't have an equivalent in .NET.  ginocanessa will come up with the list of what's allowed.

      Will define a parallel set of operations called unixToDate, unixToTime, etc. that works on Unix offset-based time representations.  The argument for it will be the timezone in which the conversion should happen.  If someone needs to convert from epochs other than the Unix epoch (1970-01-01T00:00:00), they can add or subtract a constant from the integer value before running the op.

      Show
      Will define separate operations for each target type - i.e. toDate, toTime, toDateTime, etc., each with a single argument conveying the syntax.  Will not add timezone as an argument because it can be injected into the variable on which the operation is being called.  E.g. foo = "82/11/09 5:15" foo2 = foo + "-04:00" foo2.toDateTime('yy/11/09 h:mmZZ') = "1982-11-09T05:15:00:00-04:00" Have agreed to use the Java syntax for the argument to the above functions, but will prohibit use of those features that don't have an equivalent in .NET.   ginocanessa will come up with the list of what's allowed. Will define a parallel set of operations called unixToDate, unixToTime, etc. that works on Unix offset-based time representations.  The argument for it will be the timezone in which the conversion should happen.  If someone needs to convert from epochs other than the Unix epoch (1970-01-01T00:00:00), they can add or subtract a constant from the integer value before running the op.
    • Gino Canessa/Yunwei Wang: 17-0-1
    • Enhancement
    • Compatible, substantive

    Description

      From https://jira.hl7.org/browse/FHIR-23937

      Initial proposal: 

      Currently, the parameters of the "dateOp" target transform functions are undocumented. Proposal to add two parameters:

      1. "source" - contains a string which represents a dateTime in some format (e.g. "MM/dd/yyyy H:mm", or "DD.MM.YYYY")

      2. "type" - either "time", "dateTime", "date", or "instant"

      The dateOp function should attempt to parse the source parameter and convert it into the specified type. If this cast fails, an error is thrown.

       

      Need to get agreement on what the parameters should be, then make them official.

      Attachments

        Activity

          People

            ginocanessa Gino Canessa
            lloyd Lloyd McKenzie
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: