Устранение проблем с датой и временем в приложениях на основе модели
Если значения даты и времени отключены в течение дня или нескольких часов, это может быть вызвано часовыми поясами или корректировками дневного времени. В этой статье приведены советы по устранению неполадок, таких как:
- В поле "Дата и время " отображается неправильное значение.
- В значении "Дата" отображается неправильная дата для некоторых пользователей и часовых поясов.
- В поле "Дата и время " отображается правильное значение в некоторых частях приложения, но не другие.
- После изменения значения даты и времени и его сохранения он автоматически изменяется на другое значение.
- При вводе даты переключения на летнее время приводит к тому, что дата выключена на один день или время отключается на час.
Определение проблемы с сервером или клиентом
Приложения на основе модели — это веб-приложения. Они получают данные из облачной службы Dataverse (сервер). Одни и те же данные могут использовать несколько приложений (клиентов). Ошибки могут возникать на сервере или клиенте.
Если значение даты и времени, хранящееся на сервере, неожиданно, скорее всего, будет неправильно отображаться во всех приложениях независимо от часового пояса пользователя или системы. Поэтому проверка значения сервера является важным первым шагом.
Проверка конфигурации столбца даты и времени
Dataverse поддерживает различные поведение корректировки часового пояса для столбцов даты и времени (полей). Прежде чем устранять неполадки, важно понять, как различные части системного процесса даты и времени.
Проверьте параметры столбца даты и времени на портале Power Apps или обозревателе решений:
- Учетная запись часового пояса пользователя
- Отображается ли время значения
Проверьте, хранится ли правильное значение на сервере
Значения даты и времени всегда хранятся в формате UTC на сервере. Вы можете просмотреть необработанное значение на сервере с помощью запроса веб-API.
Ниже приведен запрос, чтобы получить столбец для строки (записи).
[Organization URI]/api/data/v9.2/<entity set name>(<row id>)?$select=<column name>
Используемые имена таблиц и столбцов — это логические имена, а не отображаемые имена.
Совет
Простой способ найти идентификатор строки — открыть его в приложении на основе модели. Идентификатор можно найти в URL-адресе страницы.
В следующем примере возвращается scheduledstart столбец appointment таблицы для строки с идентификатором d2862246-4763-ee11-8def-000d3a34118b.
https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart
В адресной строке браузера в адресной строке браузера отобразится примерно следующее:
{
"@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 appointment 15 октября 2023 года, 7:30 утра. В Z конце указывается, что значение находится в формате UTC.
Предположим, что пользователь в часовом поясе UTC-8 просматривает этот столбец в приложении на основе модели. Это ожидаемые значения для различных параметров столбца.
| Поведение корректировки часового пояса | Формат | Значение, отображаемое в приложении |
|---|---|---|
| Часовой пояс пользователя | Дата и время | 14 октября 2023 г., 23:30 |
| Часовой пояс пользователя | Только дата | 14 октября 2023 г. |
| Независимо от часового пояса | Дата и время | 15 октября 2023 г., 7:30 |
| Независимо от часового пояса | Только дата | 15 октября 2023 г. |
| Только дата | - | 15 октября 2023 г. |
Если значение, отображаемое в приложении, неправильно настроено, скорее всего, это проблема клиента. Если неправильное значение сервера начинается, скорее всего, это проблема с сервером.
Проверка отформатированного значения с сервера
Корректировки часового пояса и летнего времени можно выполнить на сервере или в приложении. Если один и тот же столбец отображает другое значение в разных частях приложения, скорее всего, некоторые части приложения используют отформатированные значения с сервера, а другие делают корректировки в приложении.
Скорее всего, это проблема. Перед отправкой отчетов можно изолировать, является ли сервер или клиент проблемой, проверив форматируемое значение с сервера.
Например,
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"
Ответ будет включать значение, скорректированное сервером. В этом примере пользователь находится в часовом поясе UTC-8 и scheduledstart имеет поведение "Локальный пользователь". Поэтому форматируемое значение составляет восемь часов за необработанным значением.
{
"@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"
}
Если это отформатированное значение неправильно, это проблема с сервером. Если это правильно, это проблема клиента.
Изучение непредвиденных значений сервера
Возможные причины непредвиденных значений сервера:
- Возможно, вы не настроили поведение корректировки часового пояса и правильно отформатируйте его.
- Бизнес-правила и рабочие процессы , выполняемые на сервере, могут изменить значение до или после сохранения. В приложении клиентские скрипты могут изменить значение перед отправкой на сервер для сохранения.
Определение проблемы с настройкой или продукта
Настройки могут привести к неожиданному поведению. Следующие методы могут помочь исключить проблемы, вызванные настройками.
Отключение пользовательских скриптов
Пользовательские скрипты часто вызывают проблемы. Попробуйте временно отключить их.
Создание нового столбца даты и времени
Создание нового столбца даты и времени — самый простой способ выяснить, вызвана ли проблема ошибками конфигурации или настройками, такими как бизнес-правила. В идеале используйте другую таблицу и приложение.
Если новый столбец работает должным образом, скорее всего, это проблема с настройкой. Сравните с исходным столбцом, чтобы найти разницу.
Если новый столбец имеет ту же проблему, это может быть проблема с продуктом. Вы можете создать приложение на основе модели vanilla repro и сообщить о нем с помощью запроса на поддержку.
Попробуйте другой часовой пояс
Чтобы узнать, вызываются ли изменения часового пояса и летнего света, попробуйте изменить часовой пояс пользователя.
Существует два параметра, влияющих на часовые пояса в приложениях на основе модели:
- Часовой пояс в личных параметрах.
- Системный часовой пояс. Сведения об изменении см. в соответствующей документации в Windows, Android, iOS или macOS.
Полезные сочетания, чтобы попробовать:
- Сопоставляйте часовой пояс в личных параметрах с системным часовом поясом.
- Используйте часовой пояс UTC.
- Используйте часовой пояс с тем же смещением, но не наблюдает летнего времени.
Совет
Следующие методы содержат дополнительные сведения, чтобы упростить изучение проблем с датой и временем.
Измените формат "Только дата" на "Дата и время"
Если значение только даты отключено на день, полезно показать часть времени, чтобы узнать, могут ли корректировки часового пояса быть причиной. Вы можете временно изменить формат столбца на портале Power Apps или обозревателе решений.
Не используйте 2 цифры лет
2-значный год неоднозначный. Например, 40 могут означать 1940, 2040 или 2140. Как система интерпретирует 2 цифры лет и, скорее всего, изменится с течением времени.
Кроме того, трудно изучить, когда не отображаются значения даты и времени. По этим причинам настоятельно рекомендуется использовать 4 цифры лет, особенно при вводе дат.
Если вы не можете переключиться на 4-цифрные годы постоянно, попробуйте временно устранить неполадки.