Date parsing of FHIR date gives wrong values for non-ISO formats

[danqrodney]

trafficstars

If a questionnaire response contains an answer with a valueDate field set to '1/1/1980', the resulting FHIRDate objects have a date value of '1101-01-01', rather than '1980-01-01'.

Ideally date parsing should be smart enough to handle different common date formats, but if ISO format is required, parsing should probably fail with an error rather than generating the wrong value when a non-ISO format is provided.

[jmandel]

FHIR requires ISO-8601 date and datetime formats ― it's an error to produce a value like "valueDate": "1/1/1980", so agred, this should fail!

[p2]

Yes; the current implementation is very cheap and simply uses isodate.parse_date[time].

[rdsteed]

FHIR does not require the ISO-8601 date and datetime formats. FHIR requires that the instant, dateTime, date, and time primitive types be represented (in both XML and JSON) as various overlapping unions of XML's xs:dateTime, xs:date, xs:gYearMonth, xs:gYear, and xs:time.

The current implementation fails to deliver consistent FHIRDate representations from data that are properly formatted.

For example, in an Observation resource, effectiveDateTime is defined to be type dateTime. Yet, when I retrieve a bundle of Observation entries from a FHIR server, I receive a mixture of python date and datetime types in resource.effectiveDateTime.date .