Udostępnij za pośrednictwem

Rozwiązywanie problemów z datą i godziną w aplikacjach opartych na modelu

  • Artykuł

Gdy wartości daty i godziny są wyłączone o dzień lub kilka godzin, może to być spowodowane przez zmiany strefy czasowej lub czasu letniego. Ten artykuł zawiera porady dotyczące rozwiązywania problemów, takich jak:

  • Pole Data i godzina zawiera nieprawidłową wartość.
  • Wartość Tylko data pokazuje nieprawidłową datę dla niektórych użytkowników i stref czasowych.
  • Pole Data i godzina pokazuje poprawną wartość w niektórych częściach aplikacji, ale nie w innych.
  • Po zmianie wartości daty i godziny i zapisaniu jej automatycznie zmieni się ona na inną wartość.
  • Wprowadzenie daty przełączenia czasu letniego powoduje, że data jest wyłączona o jeden dzień lub godzina jest wyłączona o godzinę.

Określanie, czy jest to problem z serwerem, czy klientem

Aplikacje oparte na modelu to aplikacje internetowe. Pobierają dane z usługi dataverse w chmurze (serwera). Te same dane mogą zasilać wiele aplikacji (klientów). Na serwerze lub kliencie mogą wystąpić błędy.

Jeśli wartość daty i godziny przechowywana na serwerze jest nieoczekiwana, prawdopodobnie pojawi się niepoprawnie we wszystkich aplikacjach niezależnie od użytkownika lub systemowej strefy czasowej. W związku z tym sprawdzenie wartości serwera jest ważnym pierwszym krokiem.

Sprawdzanie konfiguracji kolumny daty i godziny

Usługa Dataverse obsługuje różne zachowania dostosowania strefy czasowej dla kolumn daty i godziny (pól). Przed rozpoczęciem rozwiązywania problemów należy zrozumieć, w jaki sposób różne części systemu przetwarzają wartości daty i godziny.

Sprawdź opcje kolumny daty i godziny w portalu usługi Power Apps lub eksploratorze rozwiązań:

  • Czy jest ona kontem dla strefy czasowej użytkownika
  • Czy jest wyświetlana część czasu wartości

Sprawdź, czy prawidłowa wartość jest przechowywana na serwerze

Wartości daty i godziny są zawsze przechowywane jako UTC na serwerze. Wartość pierwotną można wyświetlić na serwerze za pomocą zapytania internetowego interfejsu API.

Oto zapytanie umożliwiające pobranie kolumny dla wiersza (rekordu).

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

Używane nazwy tabel i kolumn to nazwy logiczne, a nie nazwy wyświetlane.

Porada

Łatwym sposobem znalezienia identyfikatora wiersza jest otwarcie go w aplikacji opartej na modelu. Identyfikator można znaleźć w adresie URL strony.

Poniższy przykład pobiera kolumnę scheduledstartappointment tabeli dla wiersza o identyfikatorze d2862246-4763-ee11-8def-000d3a34118b.

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

Wprowadzenie tej wartości na pasku adresu przeglądarki spowoduje wyświetlenie następujących elementów:

{
    "@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"
}

W związku scheduledstart z tym jest appointment 15 października 2023, 7:30 rano. Na Z końcu wskazuje, że wartość jest w utc.

Załóżmy, że użytkownik w strefie czasowej UTC-8 wyświetla tę kolumnę w aplikacji opartej na modelu. Są to oczekiwane wartości dla różnych opcji kolumn.

Zachowanie korekty strefy czasowej Formatowanie Wartość wyświetlana w aplikacji
Lokalny użytkownik Data i godzina 14 października 2023 r., 23:30
Lokalny użytkownik Tylko data 14 października 2023 r.
Time-Zone niezależne Data i godzina 15 października 2023 r., 7:30
Time-Zone niezależne Tylko data 15 października 2023 r.
Tylko data - 15 października 2023 r.

Jeśli wartość wyświetlana w aplikacji nie jest poprawnie dostosowana, prawdopodobnie jest to problem z klientem. Jeśli na początku wartość serwera jest niepoprawna, prawdopodobnie jest to problem z serwerem.

Sprawdzanie sformatowanej wartości z serwera

Zmiany strefy czasowej i czasu letniego można wykonać na serwerze lub w aplikacji. Jeśli ta sama kolumna pokazuje inną wartość w różnych częściach aplikacji, prawdopodobnie niektóre części aplikacji używają sformatowanej wartości z serwera, podczas gdy inne wprowadzają korekty w aplikacji.

Prawdopodobnie jest to problem. Przed zgłoszeniem można wyizolować, czy jest to problem z serwerem, czy klientem, sprawdzając sformatowaną wartość z serwera.

Na przykład:

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"

Odpowiedź będzie zawierać wartość dostosowaną przez serwer. W tym przykładzie użytkownik znajduje się w strefie czasowej UTC-8 i scheduledstart ma zachowanie lokalne użytkownika . W związku z tym sformatowana wartość jest osiem godzin za wartością nieprzetworzoną.

{
    "@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"
}

Jeśli ta sformatowana wartość jest niepoprawna, jest to problem z serwerem. Jeśli jest to poprawne, jest to problem z klientem.

Badanie nieoczekiwanych wartości serwera

Możliwe przyczyny nieoczekiwanych wartości serwera:

Określanie, czy jest to problem z dostosowywaniem, czy problem z produktem

Dostosowania mogą prowadzić do nieoczekiwanego zachowania. Poniższe metody mogą pomóc w wykluczeniu problemów spowodowanych dostosowaniami.

Wyłączanie skryptów niestandardowych

Skrypty niestandardowe często powodują problemy. Spróbuj je tymczasowo wyłączyć.

Tworzenie nowej kolumny daty i godziny

Utworzenie nowej kolumny daty i godziny jest najprostszym sposobem, aby dowiedzieć się, czy problem jest spowodowany błędami konfiguracji lub dostosowaniami, takimi jak reguły biznesowe. Najlepiej użyć innej tabeli i aplikacji.

Jeśli nowa kolumna działa zgodnie z oczekiwaniami, prawdopodobnie jest to problem z dostosowywaniem. Porównaj z oryginalną kolumną, aby znaleźć różnicę.

Jeśli nowa kolumna ma ten sam problem, może to być problem z produktem. Możesz utworzyć aplikację opartą na modelu repro wanilii i zgłosić ją za pośrednictwem wniosku o pomoc techniczną.

Wypróbuj inną strefę czasową

Aby dowiedzieć się, czy zmiany strefy czasowej i czasu letniego powodują nieoczekiwane wartości, spróbuj zmienić strefę czasowa użytkownika.

Istnieją dwa ustawienia, które wpływają na strefy czasowe w aplikacjach opartych na modelu:

  1. Strefa czasowa w opcjach osobistych.
  2. Systemowa strefa czasowa. Aby uzyskać informacje na temat sposobu jej zmiany, zapoznaj się z odpowiednią dokumentacją w systemach Windows, Android, iOS lub macOS.

Przydatne kombinacje do wypróbowania:

  • Dopasuj strefę czasowa w opcjach osobistych do systemowej strefy czasowej.
  • Użyj strefy czasowej UTC.
  • Użyj strefy czasowej z tym samym przesunięciem, ale nie obserwuje czasu letniego.

Porada

Poniższe metody zawierają więcej szczegółów, aby ułatwić badanie problemów z datą i godziną.

Zmień format "Tylko data" na "Data i godzina"

Jeśli wartość tylko daty jest wyłączona o dzień, warto pokazać część czasu, aby sprawdzić, czy przyczyną mogą być korekty strefy czasowej. Możesz tymczasowo zmienić format kolumny w portalu usługi Power Apps lub eksploratorze rozwiązań.

Nie używaj lat 2-cyfrowych

Rok 2-cyfrowy jest niejednoznaczny. Na przykład 40 może oznaczać 1940, 2040 lub 2140. Sposób, w jaki system interpretuje 2-cyfrową liczbę lat, może i prawdopodobnie zmienia się wraz z upływem czasu.

Trudno jest również zbadać, kiedy nie są wyświetlane pełne wartości daty i godziny. Z tych powodów zdecydowanie zaleca się używanie 4-cyfrowych lat, zwłaszcza podczas wprowadzania dat.

Jeśli nie możesz trwale przełączyć się na 4-cyfrowy rok, spróbuj go tymczasowo, aby pomóc w rozwiązywaniu problemów.

Zobacz też

Zachowanie i format kolumny Data i godzina