You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nur als Notiz: Wir hatten in Hannover am 10.10.24 auch darüber geredet, dass die Annahme man könne inklusive Enden in exklusive Enden nach Bedarf umrechnen, falsch ist, solange nicht auch die zeitliche Auflösung mit angegeben wird. Also z.b. "1s" oder "1d" oder "1ms" oder "1us".
Nur die Umrechnung exklusiv => "meine systemeigene Interpretation von inklusiv" ist immer möglich, die gegenrichtung i.A. nicht. Außerdem gibt es solche zeitlichen Auflösungs-Brüche nicht nur zwischen Systemen sondern auch innerhalb von Systemen, z.b. zwischen der Datenbank und einem Server.
Wir hatten auch besprochen, dass die oben beschriebene Änderung letztlich von allen Schnittstellen, die Bo4E implementieren erfordert, dass sie jegliche Kombination von inklusiv/exklusiv in einem codepfad abbilden können.
Meine persönliche Meinung bleibt, dass inklusive Enden nur Probleme machen aber ich halte mich raus uns werde auch nicht rebellieren, wenn das Gremium zur Entscheidung kommt, das sei richtig.
Noch zusätzlich - das ist ein echtes Beispiel aus der Praxis:
Wie ist der empfohlene Weg, um mit inklusiven dateonly Enden bspw. tagesscharfe Verträge abzubilden, die 1 Tag dauern?
und wie unterscheiden sich diese von Verträgen oder allgemein Zeiträumen, die 0 Tage Dauer haben, weil sie bspw. direkt wieder storniert wurden?
Wie könnte ich in inklusiven Enden die beiden Fälle auseinanderhalten?
Mit dem inklusiven Ende ist das meines Wissens nach nur möglich, wenn man sich zur Abbildung eines Sachverhalts, der an sich, in der fachlichen Domäne, nur Dates erfordert künstlich in der technischen/Bo4e Abbildung die time mit ins Haus holt, um die Probleme der inklusiven Enden zu umschiffen und 1 Tages von 0Tages-Verträgen an sowas wie enduhrzeit=23:59:59Z vs. 00:00:00Z festmacht, was ja einigermaßen hard to explain ist.
Ergebnis Zeitraum
COM Zeitraum
Vgl. #714 und #745
The text was updated successfully, but these errors were encountered: