Felsöka problem med datum och tid i modelldrivna appar
När datum- och tidsvärdena är inaktiverade med en dag eller några timmar kan det bero på tidszons- eller sommartidsjusteringar. Den här artikeln innehåller tips för att felsöka problem som:
- Fältet Datum och tid visar fel värde.
- Värdet Endast Datum visar fel datum för vissa användare och tidszoner.
- Fältet Datum och tid visar rätt värde i vissa delar av appen, men inte andra.
- När du har ändrat ett datum- och tidsvärde och sparat det ändras det automatiskt till ett annat värde.
- Om du anger ett sommartidsväxlingsdatum blir datumet avstängt med en dag eller att tiden är avstängd med en timme.
Ta reda på om det är ett server- eller klientproblem
Modelldrivna appar är webbappar. De hämtar data från Dataverse-molntjänsten (server). Samma data kan driva flera appar (klienter). Fel kan inträffa på servern eller klienten.
Om datum- och tidsvärdet som lagras på servern är oväntat visas det troligen felaktigt i alla appar oavsett användarens eller systemets tidszon. Därför är det viktigt att kontrollera servervärdet.
Kontrollera konfigurationen av datum- och tidskolumnen
Dataverse stöder olika tidszonsjusteringsbeteenden för datum- och tidskolumner (fält). Innan du felsöker är det viktigt att förstå hur olika delar av systemet bearbetar datum- och tidsvärden.
Kontrollera alternativen för datum- och tidskolumner i Power Apps-portalen eller Lösningsutforskaren :
- Om den står för en användares tidszon
- Om det visar tidsdelen av värdet
Kontrollera om rätt värde lagras på servern
Datum- och tidsvärden lagras alltid som UTC på servern. Du kan visa råvärdet på servern med en webb-API-fråga.
Här är en fråga för att hämta en kolumn för en rad (post).
[Organization URI]/api/data/v9.2/<entity set name>(<row id>)?$select=<column name>
De tabell- och kolumnnamn som används är logiska namn, inte visningsnamn.
Dricks
Ett enkelt sätt att hitta ID:t för en rad är att öppna den i en modelldriven app. ID:t finns i sid-URL:en.
I följande exempel hämtas scheduledstart kolumnen i appointment tabellen för raden med ID d2862246-4763-ee11-8def-000d3a34118b.
https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart
Om du anger detta i webbläsarens adressfält visas något som liknar följande:
{
"@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"
}
scheduledstart Därför är av den appointment 15 oktober 2023, 07:30. I Z slutet anger att värdet är i UTC.
Anta att en användare i tidszonen UTC-8 visar den här kolumnen i en modelldriven app. Det här är de förväntade värdena för de olika kolumnalternativen.
| Beteende för tidszonsjustering | Format | Värde som visas i appen |
|---|---|---|
| Användarlokalt | Datum och tid | 14 oktober 2023, 11:30 |
| Användarlokalt | Endast datum | 14 oktober 2023 |
| Tidszonsoberoende | Datum och tid | 15 oktober 2023, 07:30 |
| Tidszonsoberoende | Endast datum | 15 oktober 2023 |
| Endast datum | - | 15 oktober 2023 |
Om värdet som visas i appen inte justeras korrekt är det troligtvis ett klientproblem. Om servervärdet är felaktigt till att börja med är det troligtvis ett serverproblem.
Kontrollera det formaterade värdet från servern
Tidszons- och sommartidsjusteringar kan göras på servern eller i appen. Om samma kolumn visar ett annat värde i olika delar av appen är det troligt att vissa delar av appen använder det formaterade värdet från servern, medan andra gör justeringarna i appen.
Detta är sannolikt ett problem. Innan du rapporterar det kan du isolera om det är ett server- eller klientproblem genom att kontrollera det formaterade värdet från servern.
Ett exempel:
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"
Svaret inkluderar det värde som justeras av servern. I det här exemplet är användaren i tidszonen UTC-8 och scheduledstart har användarlokalt beteende. Därför är det formaterade värdet åtta timmar efter raw-värdet.
{
"@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"
}
Om det här formaterade värdet är felaktigt är det ett serverproblem. Om det stämmer är det ett klientproblem.
Undersöka oväntade servervärden
Möjliga orsaker till oväntade servervärden är:
- Du kanske inte har konfigurerat tidszonens justeringsbeteende och format korrekt.
- Affärsregler och arbetsflöden som körs på servern kan ändra värdet före eller efter att det har sparats. I en app kan klientskript ändra värdet innan de skickas till servern för att spara.
Ta reda på om det är ett anpassningsproblem eller produktproblem
Anpassningar kan leda till oväntat beteende. Följande metoder kan hjälpa till att utesluta problem som orsakas av anpassningar.
Inaktivera anpassade skript
Anpassade skript orsakar ofta problem. Försök att inaktivera dem tillfälligt.
Skapa en ny datum- och tidskolumn
Att skapa en ny datum- och tidskolumn är det enklaste sättet att ta reda på om problemet orsakas av konfigurationsfel eller anpassningar som affärsregler. Använd helst en annan tabell och app.
Om den nya kolumnen fungerar som förväntat är det sannolikt ett anpassningsproblem. Jämför med den ursprungliga kolumnen för att hitta skillnaden.
Om den nya kolumnen har samma problem kan det vara ett produktproblem. Du kan skapa en vanilj-repro modelldriven app och rapportera den via en supportbegäran.
Prova en annan tidszon
Om du vill ta reda på om tidszons- och sommartidsjusteringar orsakar oväntade värden kan du prova att ändra användarens tidszon.
Det finns två inställningar som påverkar tidszoner i modelldrivna appar:
- Tidszon i personliga alternativ.
- Systemtidszon. Information om hur du ändrar den finns i respektive dokumentation i Windows, Android, iOS eller macOS.
Användbara kombinationer att prova:
- Matcha tidszonen i personliga alternativ med systemets tidszon.
- Använd UTC-tidszon.
- Använd en tidszon med samma förskjutning, men observera inte sommartid.
Dricks
Följande metoder ger mer information för att göra det enklare att undersöka problem med datum och tid.
Ändra formatet "Endast datum" till "Datum och tid"
Om ett värde endast för datum är inaktiverat per dag är det bra att visa tidsdelen för att se om tidszonsjusteringar kan vara orsaken. Du kan tillfälligt ändra kolumnformatet i Power Apps-portalen eller Solution Explorer.
Använd inte 2-siffriga år
Det tvåsiffriga året är tvetydigt. Till exempel kan 40 betyda 1940, 2040 eller 2140. Hur systemet tolkar 2-siffriga år kan och kommer sannolikt att förändras över tid.
Det är också svårt att undersöka när fullständiga datum- och tidsvärden inte visas. Därför rekommenderar vi starkt att du använder 4-siffriga år, särskilt när du anger datum.
Om du inte kan växla till 4-siffriga år permanent kan du prova det tillfälligt för att felsöka.