Probleme mit Datum und Uhrzeit in modellgesteuerten Apps beheben
Wenn Datums- und Uhrzeitwerte nach einem Tag oder ein paar Stunden deaktiviert sind, kann dies durch Zeitzonen- oder Sommerzeitanpassungen verursacht werden. Dieser Artikel enthält Tipps zur Problembehandlung, z. B.:
- Das Feld "Datum" und "Uhrzeit " zeigt den falschen Wert an.
- Der Wert "Date only " 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, aber nicht in anderen Teilen an.
- Nachdem Sie einen Datums- und Uhrzeitwert geändert und gespeichert haben, wird er automatisch in einen anderen Wert geändert.
- Die Eingabe eines Sommerwechseldatums führt dazu, dass das Datum um einen Tag oder die Abwesenheitszeit um eine Stunde erfolgt.
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) bereitstellen. Fehler können auf dem Server oder Client auftreten.
Wenn der auf dem Server gespeicherte Datums- und Uhrzeitwert unerwartet ist, wird er wahrscheinlich unabhängig von der Zeitzone des Benutzers oder des Systems in allen Apps falsch angezeigt. 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 Systemprozessdatums- und -uhrzeitwertes sind.
Überprüfen Sie die Optionen für Datum und Uhrzeit im Power Apps-Portal oder Im Projektmappen-Explorer:
- Gibt an, ob die Zeitzone eines Benutzers verwendet 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.
Hier ist eine Abfrage zum Abrufen einer Spalte für eine Zeile (Datensatz).
[Organization URI]/api/data/v9.2/<entity set name>(<row id>)?$select=<column name>
Die verwendeten Tabellen- und Spaltennamen sind logische Namen und 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-000d3a34118bab.
https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart
Wenn Sie dies in die Adressleiste des Browsers eingeben, wird etwa 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 der scheduledstart der appointment 15. Oktober 2023, 7:30 Uhr. Das Z Ende gibt an, dass sich der Wert in UTC befindet.
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.
| Anpassungsverhalten der Zeitzone | Format | In der App angezeigter Wert |
|---|---|---|
| Ortszeit Benutzer | Datum und Uhrzeit | 14. Oktober 2023, 23:30 Uhr |
| Ortszeit Benutzer | Nur Datum | 14. Oktober 2023 |
| Zeitzonenunabhängig | Datum und Uhrzeit | 15. Oktober 2023, 7:30 Uhr |
| Zeitzonenunabhä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 falsch ist, um mit dem Server zu beginnen, ist es wahrscheinlich ein Serverproblem.
Überprüfen des formatierten Werts vom Server
Zeitzonen- und Sommerzeitsparanpassungen können auf dem Server oder in der App vorgenommen werden. Wenn in derselben Spalte in verschiedenen Teilen der App ein anderer Wert angezeigt wird, verwenden einige Teile der App den formatierten Wert vom Server, während andere die Anpassungen in der App vornehmen.
Dies ist wahrscheinlich ein Problem. Bevor Sie ihn 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 das lokale Verhalten des Benutzers auf. Daher liegt der formatierte Wert acht Stunden hinter dem Rohwert.
{
"@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 dies 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 Verhalten der Zeitzonenanpassung 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 sie zum Speichern an den Server gesendet werden.
Ermitteln, ob es sich um ein Anpassungsproblem 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 erwartungsgemäß funktioniert, handelt es sich wahrscheinlich um ein Anpassungsproblem. Vergleichen Sie mit der ursprünglichen Spalte, um den Unterschied zu finden.
Wenn die neue Spalte dasselbe Problem hat, kann es sich um ein Produktproblem handelt. Sie können eine modellgesteuerte Vanille-App erstellen und ü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:
- Zeitzone in persönlichen Optionen.
- Systemzeitzone. Informationen zum Ändern finden Sie in der entsprechenden Dokumentation unter Windows, Android, iOS oder macOS.
Nützliche Kombinationen zum Ausprobieren:
- Stimmen Sie die Zeitzone in persönlichen Optionen mit der Systemzeitzone überein.
- Verwenden Sie utc-Zeitzone.
- Verwenden Sie eine Zeitzone mit demselben Offset, beobachten sie jedoch nicht die Sommerzeit.
Tipp
Die folgenden Methoden bieten weitere Details, um die Untersuchung von Datums- und Uhrzeitproblemen zu vereinfachen.
Ändern des Formats "Nur Datum" in "Datum und Uhrzeit"
Wenn ein Wert nur für datumsfrei ist, ist es hilfreich, den Zeitteil anzuzeigen, um festzustellen, ob Anpassungen der Zeitzone die Ursache sein könnten. Sie können das Spaltenformat vorübergehend im Power Apps-Portal oder Im Projektmappen-Explorer ändern.
Verwenden Sie keine zweistelligen Jahre.
Das zweistellige Jahr ist mehrdeutig. Beispielsweise bedeutet "40" 1940, 2040 oder 2140. 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.