Stream: german (d-a-ch)
Topic: Instant ohne Zeitzone
Markus Danz (Feb 12 2019 at 13:14):
Laut STU3 datatypes ist ein Instant eine vollständige Datumsangabe inklusive Zeit und Zeitzone.
An instant in time - known at least to the second and always includes a time zone. Note: This is intended for precisely observed times (typically system logs etc.), and not human-reported times - for them, use date and dateTime. instant is a more constrained dateTime
Wenn ich jetzt z.B. eine DocumentReference, wo das Element "indexed" vom Typ "Instant" ist, gegen das HL7 Basisprofil "DocumentReference" mit Hilfe von FHIR.NET einlese und validiere, dann werden fehlende Zeitzonen durch die local timezone ersetzt, z.B. "+01:00". Dadurch ist es unmöglich, eine fehlende Zeitzone zu erkennen und entsprechend zu reagieren.
Im sorce code sieht man, dass FHIR.NET in der Datei ".Hl7.Fhir.Core\Model\Instant.cs" die .NET Methoden DateTimeOffset.TryParse() und DateTimeOffset.Nowverwendet. Das ist nicht restriktiv genug, um der FHIR Spezifikation zu genügen.
Lustigerweise macht simplifier etwas ähnliches. Wenn die Zeitzone fehlt, dann wird einfach +00:00 als Zeitzone angenommen und der String verändert. Hier ein Beispiel: https://simplifier.net/justforfun/documentreference-example
Hochgeladen wurde der String "2005-12-24T09:43:41" und nach dem hochladen steht "2005-12-24T09:43:41+00:00" drin.
Frage: Darf für invalide Zeit-Strings für den Typ Instant die Zeitzone einfach generiert werden? Das erscheint uns falsch.
Stefan Lang (Feb 12 2019 at 18:23):
Es ist zumindest ein pragmatischer Ansatz, aber meines Wissens so nicht in der FHIR-Spec. zu finden und sicher diskussionswürdig.
Dass Simplifier sich ähnlich verhält, ist klar - Simplifier benutzt die Dotnet-Library.
Wäre sicher ein Thema für den implementers-Stream.
Evtl. weiß auch @Alexander Zautke mehr?
Alexander Zautke (Feb 12 2019 at 18:35):
Das “gewünschte” Result wäre dann, dass die Resource nicht akzeptiert wird und der Parser einen Fehler schmeißt, verstehe ich das so richtig?
Christof Gessner (Feb 12 2019 at 19:23):
Nicht der Parser - der validator. Oder? Keine Ahnung, wie das die angesprochene Library hält, aber im allgemeinen gibt es validierende und nicht-validierende Parser (option "strict", oder sowas ähnliches meistens).
Christof Gessner (Feb 12 2019 at 19:28):
Netter topic zu ähnlichen Fragen: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Client.20Timezone
- mit der interessanten Idee, dass der Client dem Server seinen Zeit-Offset im HTTP header mitteilt. Der "nicht-validierende" Parser dürfte das u.U. verwenden - der "validierende" jedoch nicht, IMHO. Siehe hier: https://tools.ietf.org/html/draft-sharhalakis-httptz-05
Alexander Zautke (Feb 13 2019 at 09:24):
Habe das Thema intern an das API Team weitergegeben, wir schauen uns den Fall an. Sobald ich eine Ticket Nummer dazu hab, reiche ich diese nach. Ich denke der Validator sollte es klar zurückweisen. Unschlüssig bin ich beim Parser. Ich stimme Christof zu, dass sein Setting in diesem Fall hilfreich wäre.
Alexander Zautke (Feb 13 2019 at 09:25):
Danke fürs Melden :)
Stefan Lang (Feb 13 2019 at 10:50):
Ich denke, per Default sollte der Parser sich standardkonform verhalten. Dass es dann einen "lazy"- oder "non-strict"-Parameter gibt, mit dem man solche Heuristiken einschalten kann, mag wie gesagt sicher in bestimmten Use Cases pragmatisch sein.
Alexander Zautke (Feb 13 2019 at 11:40):
Validation Bug: https://github.com/ewoutkramer/fhir-net-api/issues/865
Alexander Zautke (Feb 13 2019 at 11:44):
Für den Parser wird es kein Setting geben, da wir auf dieser Ebene keine genaueren Typinformationen haben (instance vs. dateTime vs. date). Per default wird der String zu einem DateTimeOffset umgewandelt und UTC wird angenommen.
Alexander Zautke (Feb 13 2019 at 11:45):
Diese Regel gilt für alle DateTimeOffset Datentypen.
Markus Danz (Feb 13 2019 at 17:45):
Uns als Konsument der FHIR.NET Library ist es egal, ob der Parser oder der Validator den Fehler ekennt. Wichtig ist, dass wir irgendeine Möglichkeit haben, eine fehlende Zeitzone beim Datentyp Instant zu erkennen, wenn die FHIR.NET zum Einlesen einer Resource verwendet wird.
Christof Gessner (Feb 13 2019 at 18:13):
schematron validation filter?
Simone Heckmann (Feb 17 2019 at 09:43):
Das könnte Zusammenhängen mit einem Fehler im RegEx Pattern für dateTime in STU3. In R4 wurde das korrigiert. In STU3 wird die Korrektur mit den Technical Corrections publiziert.
Alexander Zautke (Feb 17 2019 at 13:21):
@Simone Heckmann Meinst du damit, dass in STU3 instant überhaupt keinen Regex zum Validieren besitzt? Hat jemand das schon vorgeschlagen für ein Backport?
Simone Heckmann (Feb 17 2019 at 13:23):
Schau mal im implementers Stream, da gibt aktuell eine Diskussion zum dateTime pattern. Ich kann’s leider nicht verlinken, da ich die mobile App benutze...
Alexander Zautke (Feb 17 2019 at 13:48):
Ah, ok. Vielen Dank. Das löst aber nicht das Problem hier. Weiß jemand gegen was HAPI in diesem Fall bei einem Instant Type validiert? @Patrick Werner
Patrick Werner (Feb 17 2019 at 16:03):
Hapi hat im Dstu3 Instant Validator die Regex von R4 verwendet, wurde hier also anscheinend schon gebackportet
Patrick Werner (Feb 17 2019 at 16:05):
was mich irritiert: hapi beginnt die Regex mit "-?" ansonsten alles gleich. Wie sollte eine Instant mit "-" beginnen? Übersehe ich da nun was?
(edit:) nein, ist wohl falsch und kommt aus den Referenz Klassen.
Alexander Zautke (Jul 08 2019 at 19:09):
Es ist zwar schon eine kleine Weile her, aber die C# API hat nun auch den R4 Regex implementiert. Gforge Ticket für den Backport in STU3 inklusive.
Siehe https://github.com/FirelyTeam/fhir-net-api/pull/1028
Last updated: Apr 12 2022 at 19:14 UTC
