Change Zeitraum to Zeitspanne, fix tests, change zeitspanne datetime to date and time

[hf-lkosareva]

#714

[hf-krechan]

Just a few grammar issues.
But the rest looks great. Thanks :)

[hf-krechan]

Suggested change

	gueltigkeitsZeitspanne: Optional[Zeitspanne] = None
	gueltigkeitszeitspanne: Optional[Zeitspanne] = None

[hf-kklein]

I trink the casing is still camelcase which we want to avoid?

[hf-krechan]

Suggested change

	#: Inklusiver Beginn des Zeitspannees, für den der Verbrauch angegeben wird
	#: Inklusiver Beginn der Zeitspanne, für den der Verbrauch angegeben wird

[hf-kklein]

Did you forget to push changes which you did locally maybe?

[hf-fvesely]

Diesen PR erweitern: gerade besprochen mit Kevin, Tim und Joscha: wir nehmen in der Zeitspanne statt start datetime und ende datetime folgendes:

startdatum dateonly, enddatum dateonly, (start und ende inklusiv)
startuhrzeit timeonly enduhrzeit timeonly, (start inklusiv, ende exklusiv).

(Wenn Datum und Uhrzeit angegeben sind, können sie verbunden weren zu datetime - in der jeweiligen Anwendung)

[lord-haffi]

@hf-fvesely Bzgl. der Frage, ob das mit den JSON-Schemas funktioniert: Es wird auf jeden Fall für JSON-Schemas definiert: https://json-schema.org/understanding-json-schema/reference/string#built-in-formats
Pydantic scheint das auch zu implementieren, zumindest läuft der Test für die Doku durch, welcher auch die JSON-Schemas baut.

[hf-fvesely]

@snsttr Hier sollten wir nochmal weiterdiskutieren wie eine sinnvolle Abbildung aussieeht. Evtl. Abgabefrist als Zeitpunkt und Bindefrist als Zeitmenge, oder Zeitspanne?

[hf-fvesely]

Wie gehen wir damit um, wenn Felder sowohl eine Zeitspanne als eine Zeitmenge beinhalten könnten, also so wie die alte COM Zeitraum?

[hf-fvesely]

Mögliche Lösung: Zeitraum doch noch drinlassen, als deprectaed markeiren, aber für manche Fälle noch drinlassen, wenn es wirklcih beides sein kann.
Alternativ: Felder duplizieren: abgabefristdauer, abgeabfristdatum

[lord-haffi]

Wie gehen wir damit um, wenn Felder sowohl eine Zeitspanne als eine Zeitmenge beinhalten könnten, also so wie die alte COM Zeitraum?

Optional["Zeitspanne | Zeitmenge"]? Dafür gibt's doch den Union-type :)

[hf-fvesely]

Stimmt, in einer Diskussion mit Konstantin kam allerdings die Frage auf, ob das so eine gute Idee ist, da es nicht in allen Sprachen ein Pendant zum Union-type gibt.
Da es ja an mehreren Stellen Fristen gibt, kam mir noch die Idee ein COM Frist zu erstellen, was dann beide Optionen beinhaltet. Was denkt ihr? @lord-haffi @snsttr @hf-kklein @hf-krechan @hf-aschloegl

[lord-haffi]

Naja, in den JSON-Schemas wird der Any-Of type definiert, was genau der Union-type in Python ist. Wie die einzelnen Sprachen das Pattern dann umsetzen, ist ein Problem des Code-Generators imo. Bzw. desjenigen, der das dann implementiert. Da die Typen auch disjunkt sind, sehe ich da zumindest in der Theorie auch kein Problem, da nen Union draus zu machen.
@hf-kklein Was ist deine Meinung dazu?

[hf-kklein]

startdatum dateonly, enddatum dateonly, (start und ende inklusiv)
startuhrzeit timeonly enduhrzeit timeonly, (start inklusiv, ende exklusiv).

Was wir dabei leider verlieren ist der utc offset

[lord-haffi]

startdatum dateonly, enddatum dateonly, (start und ende inklusiv)
startuhrzeit timeonly enduhrzeit timeonly, (start inklusiv, ende exklusiv).

Was wir dabei leider verlieren ist der utc offset

Alternativ: start: Optional[AwareDatetime | date | time]. Fände ich persönlich sogar besser, als es in mehrere Felder aufzuteilen.

[hf-fvesely]

Hat sich erledigt, Kevin hat den zweiten unnötigen Link gelöscht.:
@lord-haffi @hf-krechan Ich habe nochmal eine ganz andere Frage: Seit PR #831 haben wir dieses problem: https://github.com/bo4e/BO4E-python/actions/runs/9423154482/job/25960970363?pr=745. Kann man da irgednwie die Regel etwas abschwächen?

[hf-fvesely]

startdatum dateonly, enddatum dateonly, (start und ende inklusiv)
startuhrzeit timeonly enduhrzeit timeonly, (start inklusiv, ende exklusiv).

Was wir dabei leider verlieren ist der utc offset

Alternativ: start: Optional[AwareDatetime | date | time]. Fände ich persönlich sogar besser, als es in mehrere Felder aufzuteilen.

@hf-kklein Das time objekt in Python hat eine optionale Zeitzoneninfo:

https://docs.python.org/3/library/datetime.html

In JsonSchema kommt es auch bald dazu:

https://json-schema.org/understanding-json-schema/reference/string#dates-and-times

@lord-haffi Zu dem union type gab es mittlerweile einige stimmen, die sich dagegen ausgesprochen haben, da es in manch anderen Sprache eine unnötige Kompliaktion bei der Nutzung der lib dartstellen könnte, für weniger erfahrene Programmierende.
@hf-kklein da hatte Leon ja oben noch nach deiner Einschätzung gefragt.