Default message timezone support is missing

[srosenda]

Noticed that according to the HL7 specification (see e.g. https://hl7-definition.caristix.com/v2/HL7v2.5/Fields/MSH.7) if the MSH.7 - Date/Time Of Message field of the message header specifies a timezone it should be used as the default timezone for the rest of the date/time fields of the message. This feature is not implemented by the library and cannot be implemented outside of it as the current implementation eagerly parses all date & date/time fields to JavaScript Date objects assuming UTC timezone if none is specified in situ in the field itself.

The following failing test cases demonstrate the issue:

  it('should apply message header timestamp timezone to date fields in other segments', function() {
    const msg = HL7Message.parse('MSH|^~\\&|||||201506301532.123+0300|||||2.5\r' +
        'AL1|1|||||20151231\r');
    const seg = msg.getSegment('AL1');
    assert.deepStrictEqual(seg.IdentificationDate.value, new Date('2015-12-31T00:00:00.000+0300'));
  });

  it('should apply message header timestamp timezone to time fields in other segments', function() {
    const msg = HL7Message.parse('MSH|^~\\&|||||201506301532.123+0300|||||2.5\r' +
    'TQ1||||134523');
    const seg = msg.getSegment('TQ1');
    assert.deepStrictEqual(seg.ExplicitTime.value, new Date('0000-01-01T13:45:23.000+0300'));
  });

  it('should apply message header timestamp timezone to date time fields in other segments', function() {
    const msg = HL7Message.parse('MSH|^~\\&|||||201506301532.123+0300||SIU^S12|||2.5\r' +
        'SCH||||||NW^Booking appointed|||||^^20^20150830080000||||||||||||||||\r');
    const seg = msg.getSegment('SCH');
    assert.deepStrictEqual(seg.AppointmentTimingQuantity[0].StartDateTime.value, new Date('2015-08-30T08:30:00.000+0300'));
  });

Test output:

should apply message header timestamp timezone to date fields in other segments:

      AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
+ actual - expected

+ 2015-12-31T00:00:00.000Z
- 2015-12-30T21:00:00.000Z
           ^
      + expected - actual

      -[Date: 2015-12-31T00:00:00.000Z]
      +[Date: 2015-12-30T21:00:00.000Z]

should apply message header timestamp timezone to time fields in other segments:

      AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
+ actual - expected

+ 0000-01-01T13:45:23.000Z
- 0000-01-01T10:45:23.000Z
              ^
      + expected - actual

      -[Date: 0000-01-01T13:45:23.000Z]
      +[Date: 0000-01-01T10:45:23.000Z]

should apply message header timestamp timezone to date time fields in other segments:

      AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
+ actual - expected

+ 2015-08-30T08:00:00.000Z
- 2015-08-30T05:30:00.000Z
              ^
      + expected - actual

      -[Date: 2015-08-30T08:00:00.000Z]
      +[Date: 2015-08-30T05:30:00.000Z]

[srosenda]

I was thinking about this a bit more and came to the conclusion that returning the timestamps as Date objects from the HL7 parser is not the best solution considering the UTC offset in the HL7 message header. The timestamp in the header is the message creation time, but the other timestamps in the message may be times in the future or past, which may affect the UTC offset they should be interpreted in.

As an example consider a message that was created in February in Sweden (CET timezone, UTC offset +1h) containing timestamp of an appointment in April without an explicit UTC offset. In this case, according to the HL7 specification, the UTC offset of the message header (UTC+1h of the message creation time) should be used for the rest of the timestamps in the message. However, the correct UTC offset for Stockholm in April is CEST = UTC+2h. To deduce the correct time for the appointment, either the receiver of the HL7 message should add +1h to the message's default UTC offset based on the appointment's location or other information it has about the appointment. Alternatively the sender could include the correct UTC offset to the message or make similar adjustment to the appointment's timestamp. In order for the receiver to make the correction, it would need to know the UTC offset that was used in the message creation timestamp. This is not possible if the timestamp is returned as a Javascript Date object, because it is always in UTC and does not contain any information about an offset or timezone. To solve this the HL7 message parser should return timestamps as structured objects, with separate fields for date, time and UTC offset and let the client interpret the time as either local or UTC.