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 inaktiverad 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 det datum- och tidsvärde 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 verifiera 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 du förstår hur olika delar av systemprocessens 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 den 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 raw-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.
Tips
Ett enkelt sätt att hitta ID:t för en rad är att öppna den i en modelldriven app. ID:t finns i sidans URL.
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"
}
Därför är av den scheduledstartappointment 15 oktober 2023, 7:30 am. 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 |
|---|---|---|
| Lokal användare | Datum och tid | 14 oktober 2023, 23:30 |
| Lokal användare | Endast datum | 14 oktober 2023 |
| Time-Zone Oberoende | Datum och tid | 15 oktober 2023, 07:30 |
| Time-Zone Oberoende | 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 innehåller 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 rå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 dig att utesluta problem som orsakas av anpassningar.
Inaktivera anpassade skript
Anpassade skript orsakar ofta problem. Prova 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. Vi rekommenderar att du använder en annan tabell och app.
Om den nya kolumnen fungerar som förväntat är det troligtvis 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 vanilla 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 det 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 observerar inte sommartid.
Tips
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 Lösningsutforskaren.
Använd inte tvåsiffriga år
Det tvåsiffriga året är tvetydigt. 40 kan till exempel betyda 1940, 2040 eller 2140. Hur systemet tolkar 2-siffriga år kan och kommer sannolikt att förändras med tiden.
Det är också svårt att undersöka när fullständiga datum- och tidsvärden inte visas. Av dessa skäl rekommenderar vi starkt att du använder 4-siffriga år, särskilt när du anger datum.
Om du inte kan byta till 4-siffriga år permanent kan du prova det tillfälligt för att felsöka.