Flatencoding parsing: automatically handle date/time/date_time precision

[mhenke-vg]

Make the implementation handle input that does not fit perfectly by taking the parts that can be used

e.g. DateTime input into Date field only takes the date part

[stefanspiska]

can you please add test.

In fact there are test for this bug in org.ehrbase.conformance_test.extern.tests.SettersTest wich you could simple enable by remover the overwrite
also you have Errors in you tesst

[serefarikan]

@mhenke-vg @stefanspiska This is surely an interesting one. May I be the devil's advocate and remind that according to openEHR RM, there is not a IS_A relationship between Date and DateTime types. If I was the developer using the flat encoding, I'd expect a DateTime input into a Date field to fail because of this.

If a DateTime is provided, at least as per the RM, it means the time is significant, and I'd say it'd have to be valid or invalid as a whole. What if someone is recording the time some medication was administered at 15:00 PM during the day, and the next dose must be taken at 23:00 PM. If the conversion to Date falls back to mid day for the time component, then the patient would be given the medication at 20:00, and would risk having a stomach bleeding etc..

Apologies if I misunderstood things, just thought I'd raise the point :)

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication

[freshehr]

For what it is worth, I partly agree with @serefarikan here. The original archetype designer will have selected DV_DATE for a reason, and it feels as if there might be some potential risk if a full DateTime is being automatically curtailed to to Date inside the CDR. I do think it is probably valid to do so in the majority of cases but I'd have preferred for this to be checked first for clinical safety and any safe transform applied outside the CDR.