Invalid characters in date

[Shannon]

FYI, you have done a tremendous work here.

I am trying out an input example from the documentation for a piece of lab equipment. I have not confirmed if this is the actual message coming from the device, but the doc gives this example for a header (MSH):

MSH|^~&|Sight Diagnostics OLO q497||||2019-07-02 12:23:24+0300||OUL^R22^OUL_R22|sld-q29-1871|P|2.5

Reading it with this code:

func decode(message []byte) error {
	d := hl72.NewDecoder(h250.Registry, nil)
	result, err := d.Decode(message)
	if err != nil {
		return err
	}
	_ = result
	return nil
}

This produces an error:

segment list: line 1, MSH.DateTimeOfMessage: time.Time.7: invalid characters in date: "2019-07-02 12:23:24+0300"

I imagine it's the timezone that is not expected. The lame thing is that the response date in the doc is a totally different format:

2019-07-02^12:23:24

Anyway, a difficult problem, because clearly you cannot just throw one time.Parse format at it, but try a few of them and see what works.

[Shannon]

After more testing, it wasn't the timezone. Looks like its the space. However, when I tried this for the date:

2019-07-02^12:23:24+0300

I got a fatal panic:
panic: runtime error: slice bounds out of range [:12] with length 7 [recovered]
panic: runtime error: slice bounds out of range [:12] with length 7

[Daniel Theophanes]

In HL7, datetimes don't have any delimiters, that is, the format should be something like "YYYYMMDDHHmm". I should probably fix the panic however, and ideally display a better error message showing the field value and the expected format.

You can get around this by creating a new message type. You could copy h250 (for instance), and alter the definitions of the fields to a string, then do a manual conversion to time.Time.

[Deleted user]

Obviously you cannot control what a machine will send at you. What the format should be isn't always what you get, and I like how in other parts of your code, you make admissions to this and are flexible, like with newlines vs. CR.

Would you be open to me make some edits to parsetime to fix the crash and accept dates also in the nonstandard format?

[Daniel Theophanes]

It should not crash, no. I would be okay with those edits.

If you wanted to make a separate change, in the realm of "try harder on date parsing" or custom date parser options, I would consider it.