Verstehe Datum und Zeit in Model-Driven Apps
In vielen professionellen Anwendungsfällen werden Daten und Zeiten verarbeitet. Dataverse bietet verschiedene Möglichkeiten diese zu speichern und anzuzeigen, was häufig zu Verwirrungen führt. Wer am Anfang die Datentypen nicht richtig setzt, hat später evtl. Schwierigkeiten bei der Verarbeitung. Hier erfährst du wie die am besten mit Datums- und Zeitfeldern umgehst.
Datum und zeit verstehen
Dataverse bietet eine Reihe von Möglichkeiten Datums- und Zeit-Felder zu erstellen. Diese unterscheiden sich darin, welche Daten tatsächlich gespeichert werden, wie sie angezeigt werden und wie sie später verarbeitet werden können. Auch mir ist es in der Vergangenheit passiert, dass ich zwei Daten verarbeiten wollte, nur um festzustellen, dass die gespeicherten Daten es nicht zulassen, oder die Technik es mir, in der Form von Berechnete Spalten, gar verboten hat. Welche Möglichkeiten gibt es hier?
In Dataverse und Model-Driven Apps gibt es effektiv zwei Parameter für Datumsfelder: Format und Zeitzonenanpassung. Bei der Erstellung einer neuen Spalte gibt es auch noch den Datentyp, dieser lässt sich aber nicht unabhängig vom Format einstellen.
Das Format kennt zwei Einstellungen: „Datum und Uhrzeit“ und „Nur Datum“. Die Zeitzonenanpassung kennt bis zu drei Einstellungen: „Lokaler Benutzer“, „Zeitzonenunabhängig“ und „Nur Datum“. Letzteres ist nur verfügbar, wenn auch das Format auf „Nur Datum“ steht.
Format
Das Format bestimmt wie Datums- und Zeitfelder angezeigt werden bzw. was in Formularen eingegeben werden kann.
- Wie der Name schon sagt werden beim Format „Datum und Uhrzeit“ das Datum und die Uhrzeit angezeigt.
- Bei „Nur Datum“ wird nur das Datum angezeigt.
Dies betrifft aber nur die Anzeige bzw. die Eingabe. Die dahinterliegenden Daten werden als Zeitstempel mit Datum und Uhrzeit gespeichert. Da man in Model-Driven Apps bei Date only keine Uhrzeit eingeben kann wird hier die Zeit-Komponente auf 00:00 Uhr gesetzt.
Zeitzonenanpassung
Die Zeitzonenanpassung ist, was die meisten Entwickler verwirrt und wo die meisten Probleme auftauchen. Die Zeitzonenanpassung beschreibt, wie die gespeicherten Daten in unterschiedlichen Zeitzonen angezeigt werden. Dabei gibt es die folgenden Möglichkeiten:
- Lokaler Benutzer (User local): Hierbei wird davon ausgegangen, dass die Nutzer die Zeit in ihrer lokalen Zeit eingeben. Die Daten werden in UTC konvertiert und als UTC gespeichert. Bei der Anzeige werden die UTC-Daten wieder in die lokale Zeit der Nutzer konvertiert.
- Zeitzonenunabhängig (Time Zone Independent/TZI): Hierbei werden die Daten genau so gespeichert wie die Nutzer sie eingeben. Weder bei der Eingabe, noch bei der Anzeige findet eine Konvertierung statt.
- Nur Datum (Date only): Diese Einstellung ist nur verfügbar, wenn auch das Format auf Date only steht. Hierbei wird nur das Datum gespeichert ohne eine Zeitkoponente. Die Daten werden genau so gespeichert, wie sie eingegeben wurden und werden auch genau so angezeigt.
Viele Möglichkeiten
Für sich genommen scheint das System nicht besonders kompliziert. Das Format bestimmt, was der Nutzer sieht. Die Zeitzonenanpassung bestimmt, ob die Information zeitzonenspezifisch angepasst wird. Allerdings gibt es somit fünf verschiedene Möglichkeiten Datums- und Zeit-Felder zu konfigurieren: Datetime-Format mit User local oder TZI, sowie Date only mit User local, TZI oder Date only Anpassung. Welche nimmt man nun in welchem Fall?
Im Prinzip gibt es nur drei Fälle, die für dich relevant sind: Date only, User local oder Time Zone Independent.
- „Nur Datum“ wird immer dann benutzt, wenn es nur um das Datum geht (z.B. Feiertage, Geburtstage, etc.). Die Zeit ist hier irrelevant und entsprechend auch keine Zeitzoneninformationen notwendig. Du stellst es ein, indem du das Format auf Date Only stellst und die Zeitzonenanpassung auf TZI. Auf keinen Fall solltest du die Zeitzonenberechtigung auf User local stellen, da dies zu Fehlinformationen führen kann (siehe weiter unten). Du kannst die Zeitzonenanpassung auch auf Date only stellen, dies kann dich aber bei der Weiterverarbeitung einschränken.
- „Zeitzonenunabhängig““ solltest du dann nutzen, wenn die angezeigten Zeiten unabhängig von der Zeitzone immer gleich bleiben sollen. Wenn ich z.B. in den Urlaub fliege, dann möchte ich schon zu Hause in Deutschland wissen, was die Check-Out-Zeiten meines Hotels vor Ort sind. Es bringt mir nichts zu wissen, wie viel Uhr es dann in Deutschland ist. In diesem Fall stellst du das Format auf Datetime und die Zeitzonenanpassung auf TZI.
- „Lokaler Benutzer“ solltest du nutzen, wenn es wichtig ist die Informationen in der aktuellen Zeit des Nutzers anzuzeigen oder wenn es um die tatsächliche chronologische Reihenfolge geht. Bei einem IT-Ticket-System z.B. möchte man meistens wissen wann das Ticket tatsächlich erstellt wurde. Da wäre es schlecht, wenn ein Nutzer in New York die gleiche Zeit angezeigt bekäme wie ein Nutzer in Mumbai. User local stellst du ein, in dem du das Format auf Datetime und die Zeitzonenanpassung auf User local stellst.
| Format | Eingabe (UTC+2) | Dataverse | Ausgabe (UTC-5) |
|---|---|---|---|
| Date only/TZI | 2025-03-21 | 2025-03-21T00:00 | 2025-03-21 |
| Datetime/TZI | 2025-03-21T23:11 | 2025-03-21T23:11 | 2025-03-21T23:11 |
| Datetime/Use local | 2025-03-21T23:11 | 2025-03-21T21:11 | 2025-03-21T16:11 |
Eingabe und Ausgabe über Model-Driven App form.
Was ist mit den anderen Möglichkeiten?
Wenn du sowohl das Format, als auch die Zeitzonenanpassung auf Date only stellst, wir nur data Datum und keine Zeitinformation gespeichert. Dies kann durchaus sinnvoll sein, bietet aber in der Regel keinen Mehrwert gegenüber Date only Format mit TZI. Ein Nachteil ist aber, dass man in diesem Fall bei berechneten Spalten eingeschränkt ist. Denn man kann (bezogen auf die Zeitzonenanpassung) Date only Felder nicht mit TZI oder User local Feldern kombinieren.
Date only Format mit User local Zeitzonenanpassung solltest du unbedingt vermeiden. Hierbei wird nur das Datums-Feld angezeigt, es findet aber trotzdem im Hintergrund eine Zeitzonenanpassung statt. Wenn ich also in Deutschland bin und den 19.3.2025 eingebe, dann wird der 19.3.2025 00:00 Uhr übermittelt. Wegen der Zeitzonenberichtigung wird aber die entsprechende UTC-Zeit gespeichert, der 18.3.2025 23:00 Uhr. Mir fällt das nicht auf, da bei der Anzeige die Zeit wieder konvertiert wird. Für meine Kollegen in den USA wird aber der 18.3.2025 angezeigt werden. Diese Diskrepanz ist meistens nicht gewollt und führt zu Fehlinformationen.
| Format | Eingabe (UTC+2) | Dataverse | Ausgabe (UTC-5) |
|---|---|---|---|
| Date only/Date only | 2025-03-21 | 2025-03-21 | 2025-03-21 |
| Date only/User local | 2025-03-21 | 2025-03-20T22:00 | 2025-03-20 |
Vermeide Date only mit User local zu kombinieren.
Power Automate
Bis jetzt bezog sich alles auf die Eingabe und Anzeige von Daten in Model-Driven Apps. In vielen Applikationen laufen aber Power Automate Flows im Hintergrund. Hierbei ist wichtig zu wissen, dass Power Automate bei der Speicherung die Zeitzonenanpassung nicht beachtet. Jede Eingabe wird so gespeichert wie sie übergeben wird, unabhängig von der Zeitzone des Nutzers, in dessen Context die Aktion läuft. Lediglich bei der formatierten Ausgabe wird ggf. die User local Zeit oder Date only Format berücksichtigt. Das führt dazu, dass du in der Regel die Datumseingabe bei Power Automate mit der Funktion utcNow() machen solltest. Dies kommt aber auch auf den Anwendungsfall an.
| Format | Eingabe (UTC+2) | Dataverse | Ausgabe (UTC-5) |
|---|---|---|---|
| Date only/Date only | 2025-03-21T23:11 | 2025-03-21T23:11 | 2025-03-21T23:11 |
| Datetime/TZI | 2025-03-21T23:11 | 2025-03-21T23:11 | 2025-03-21T23:11 |
| Datetime/User local | 2025-03-21T23:11 | 2025-03-21T23:11 | 2025-03-21T23:11 |
In Power Automate werden Daten gespeichert, wie sie eingegeben werden.
Fazit
Dataverse bietet eine Reihe von Möglichkeiten Datums- und Zeitfelder zu formatieren. Je nach Anwendungsfall mit oder ohne Zeitzonenanpassung. Dies kann verwirrend sein, aber wenn du die folgenden Best Practises befolgst sollte es keine Probleme geben.
- Wenn du nur das Datum brauchst, nutze Date only mit TZI.
- Wenn du eine feste Zeit brauchst, die überall auf der Welt gleich ist, nutze Datetime mit TZI.
- Wenn du die Nutzerzeit oder tatsächliche Reihenfolge brauchst, nutze Datetime mit User local.
- Kombinieren Date only nie mit User local.
- Passe bei Power Automate auf, denn dort werden die Zeiten so gespeichert wie sie eingegeben werden.
Kommentare
Leo Redlich
2025-03-31
Ein neuer Kommentar
Schreibe ein Kommentar
Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert