Freigeben über

Behandeln von Datums- und Uhrzeitproblemen in modellgesteuerten Apps

  • Artikel

Wenn Datums- und Uhrzeitwerte um einen Tag oder einige Stunden deaktiviert sind, kann dies durch Zeitzonen- oder Sommerzeitanpassungen verursacht werden. Dieser Artikel enthält Tipps zur Behandlung von Problemen, z. B.:

  • Das Feld Datum und Uhrzeit zeigt den falschen Wert an.
  • Der Wert Nur Datum zeigt das falsche Datum für einige Benutzer und Zeitzonen an.
  • Das Feld Datum und Uhrzeit zeigt den richtigen Wert in einigen Teilen der App an, in anderen jedoch nicht.
  • Nachdem Ein Datums- und Uhrzeitwert geändert und gespeichert wurde, wird er automatisch in einen anderen Wert geändert.
  • Die Eingabe eines Sommerzeitumstellungsdatums führt dazu, dass das Datum um einen Tag oder die Zeit um eine Stunde ausgeschaltet wird.

Ermitteln, ob es sich um ein Server- oder Clientproblem handelt

Modellgesteuerte Apps sind Web-Apps. Sie erhalten Daten vom Dataverse-Clouddienst (Server). Dieselben Daten können mehrere Apps (Clients) mit Strom versorgt werden. Fehler können auf dem Server oder Client auftreten.

Wenn der auf dem Server gespeicherte Datums- und Uhrzeitwert unerwartet ist, wird er wahrscheinlich in allen Apps falsch angezeigt, unabhängig von Benutzer- oder Systemzeitzone. Daher ist die Überprüfung des Serverwerts ein wichtiger erster Schritt.

Überprüfen der Konfiguration der Datums- und Uhrzeitspalte

Dataverse unterstützt verschiedene Zeitzonenanpassungsverhalten für Datums- und Uhrzeitspalten (Felder). Vor der Problembehandlung ist es wichtig zu verstehen, wie verschiedene Teile des Systemprozesses Datums- und Uhrzeitwerte aufweisen.

Überprüfen Sie die Spaltenoptionen für Datum und Uhrzeit im Power Apps-Portal oder im Projektmappen-Explorer:

  • Gibt an, ob die Zeitzone eines Benutzers berücksichtigt wird.
  • Gibt an, ob der Zeitteil des Werts angezeigt wird.

Überprüfen, ob der richtige Wert auf dem Server gespeichert ist

Datums- und Uhrzeitwerte werden immer als UTC auf dem Server gespeichert. Sie können den Rohwert auf dem Server mit einer Web-API-Abfrage anzeigen.

Im Folgenden finden Sie eine Abfrage zum Abrufen einer Spalte für eine Zeile (einen Datensatz).

[Organization URI]/api/data/v9.2/<entity set name>(<row id>)?$select=<column name>

Die verwendeten Tabellen- und Spaltennamen sind logische Namen, keine Anzeigenamen.

Tipp

Eine einfache Möglichkeit, die ID einer Zeile zu finden, besteht darin, sie in einer modellgesteuerten App zu öffnen. Die ID finden Sie in der Seiten-URL.

Im folgenden Beispiel wird die scheduledstart Spalte der appointment Tabelle für die Zeile mit der ID d2862246-4763-ee11-8def-000d3a34118babgerufen.

https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart

Wenn Sie dies in der Adressleiste des Browsers eingeben, wird folgendes angezeigt:

{
    "@odata.context": "https://myorg.crm.dynamics.com/api/data/v9.2/$metadata#appointments(scheduledstart)/$entity",
    "@odata.etag": "W/\"11472725\"",
    "scheduledstart": "2023-10-15T07:30:00Z",
    "activityid": "d2862246-4763-ee11-8def-000d3a34118b"
}

Daher ist die scheduledstart der appointment 15. Oktober 2023, 7:30 Uhr. Der Z am Ende gibt an, dass der Wert in UTC liegt.

Angenommen, ein Benutzer in der Zeitzone UTC-8 zeigt diese Spalte in einer modellgesteuerten App an. Dies sind die erwarteten Werte für die verschiedenen Spaltenoptionen.

Zeitzonenanpassungsverhalten Format In der App angezeigter Wert
Benutzer lokal Datum und Uhrzeit 14. Oktober 2023, 23:30 Uhr
Benutzer lokal Nur Datum 14. Oktober 2023
Time-Zone Unabhängig Datum und Uhrzeit 15. Oktober 2023, 7:30 Uhr
Time-Zone Unabhängig Nur Datum 15. Oktober 2023
Nur Datum - 15. Oktober 2023

Wenn der in der App angezeigte Wert nicht ordnungsgemäß angepasst wird, handelt es sich wahrscheinlich um ein Clientproblem. Wenn der Serverwert zu Beginn falsch ist, handelt es sich wahrscheinlich um ein Serverproblem.

Überprüfen des formatierten Werts vom Server

Zeitzonen- und Sommerzeitanpassungen können auf dem Server oder in der App vorgenommen werden. Wenn dieselbe Spalte einen anderen Wert in verschiedenen Teilen der App anzeigt, verwenden einige Teile der App wahrscheinlich den formatierten Wert vom Server, während andere die Anpassungen in der App vornehmen.

Dies ist wahrscheinlich ein Problem. Bevor Sie dies melden, können Sie isolieren, ob es sich um ein Server- oder Clientproblem handelt, indem Sie den formatierten Wert vom Server überprüfen.

Beispiel:

GET https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart
Accept: application/json
OData-MaxVersion: 4.0
OData-Version: 4.0
Prefer: odata.include-annotations="OData.Community.Display.V1.FormattedValue"

Die Antwort enthält den vom Server angepassten Wert. In diesem Beispiel befindet sich der Benutzer in der UTC-8-Zeitzone und scheduledstart weist ein lokales Benutzerverhalten auf. Daher liegt der formatierte Wert acht Stunden hinter dem Unformatierten Wert.

{
    "@odata.context": "https://myorg.crm.dynamics.com/api/data/v9.2/$metadata#appointments(scheduledstart)/$entity",
    "@odata.etag": "W/\"11472725\"",
    "scheduledstart@OData.Community.Display.V1.FormattedValue": "10/14/2023 11:30 PM",
    "scheduledstart": "2023-10-15T07:30:00Z",
    "activityid": "2ad8786a-9164-ee11-9ae7-0022480a0700"
}

Wenn dieser formatierte Wert falsch ist, handelt es sich um ein Serverproblem. Wenn es richtig ist, handelt es sich um ein Clientproblem.

Untersuchen unerwarteter Serverwerte

Mögliche Gründe für unerwartete Serverwerte sind:

  • Möglicherweise haben Sie das Zeitzonenanpassungsverhalten und das Format nicht ordnungsgemäß konfiguriert.
  • Geschäftsregeln und Workflows , die auf dem Server ausgeführt werden, können den Wert vor oder nach dem Speichern ändern. Innerhalb einer App können Clientskripts den Wert ändern, bevor er zum Speichern an den Server gesendet wird.

Ermitteln, ob es sich um ein Anpassungs- oder Produktproblem handelt

Anpassungen können zu unerwartetem Verhalten führen. Mit den folgenden Methoden können Sie Probleme ausschließen, die durch Anpassungen verursacht werden.

Deaktivieren von benutzerdefinierten Skripts

Benutzerdefinierte Skripts verursachen häufig Probleme. Versuchen Sie , sie vorübergehend zu deaktivieren.

Erstellen einer neuen Datums- und Uhrzeitspalte

Das Erstellen einer neuen Datums- und Uhrzeitspalte ist die einfachste Möglichkeit, herauszufinden, ob das Problem durch Konfigurationsfehler oder Anpassungen wie Geschäftsregeln verursacht wird. Verwenden Sie idealerweise eine andere Tabelle und App.

Wenn die neue Spalte wie erwartet funktioniert, handelt es sich wahrscheinlich um ein Anpassungsproblem. Vergleichen Sie mit der ursprünglichen Spalte, um den Unterschied zu ermitteln.

Wenn die neue Spalte das gleiche Problem aufweist, kann es sich um ein Produktproblem handelt. Sie können eine modellgesteuerte Vanilla-Repro-App erstellen und diese über eine Supportanfrage melden.

Probieren Sie eine andere Zeitzone aus.

Um herauszufinden, ob Zeitzonen- und Sommerzeitanpassungen unerwartete Werte verursachen, versuchen Sie, die Zeitzone des Benutzers zu ändern.

Es gibt zwei Einstellungen, die sich auf Zeitzonen in modellgesteuerten Apps auswirken:

  1. Zeitzone in persönlichen Optionen.
  2. Systemzeitzone. Informationen zum Ändern finden Sie in der entsprechenden Dokumentation unter Windows, Android, iOS oder macOS.

Nützliche Kombinationen zum Ausprobieren:

  • Passen Sie die Zeitzone in den persönlichen Optionen der Systemzeitzone an.
  • Verwenden Sie die UTC-Zeitzone.
  • Verwenden Sie eine Zeitzone mit demselben Offset, aber keine Sommerzeit.

Tipp

Die folgenden Methoden bieten weitere Details, um die Untersuchung von Datums- und Uhrzeitproblemen zu erleichtern.

Ändern Sie das Format "Nur Datum" in "Datum und Uhrzeit".

Wenn ein Datums-only-Wert um einen Tag deaktiviert ist, ist es hilfreich, den Zeitteil anzuzeigen, um festzustellen, ob Zeitzonenanpassungen die Ursache sein könnten. Sie können das Spaltenformat vorübergehend im Power Apps-Portal oder im Projektmappen-Explorer ändern.

Verwenden Sie keine 2-stelligen Jahre

Das 2-stellige Jahr ist mehrdeutig. Beispielsweise kann 40 1940, 2040 oder 2140 bedeuten. Wie das System 2-stellige Jahre interpretiert, kann und wird sich wahrscheinlich im Laufe der Zeit ändern.

Es ist auch schwierig zu untersuchen, wann die vollständigen Datums- und Uhrzeitwerte nicht angezeigt werden. Aus diesen Gründen wird dringend empfohlen, vierstellige Jahre zu verwenden, insbesondere bei der Eingabe von Datumsangaben.

Wenn Sie nicht dauerhaft zu vierstelligen Jahren wechseln können, versuchen Sie es vorübergehend, um die Problembehandlung zu unterstützen.

Siehe auch

Verhalten und Format der Spalte "Datum" und "Uhrzeit"