Поделиться через


Устранение проблем с датой и временем в приложениях на основе модели

Если значения даты и времени отключены на день или несколько часов, это может быть вызвано корректировкой часового пояса или переходом на летнее время. В этой статье содержатся советы по устранению таких проблем, как:

  • В поле Дата и время отображается неправильное значение.
  • Значение Только дата показывает неправильную дату для некоторых пользователей и часовых поясов.
  • В поле Дата и время отображается правильное значение в некоторых частях приложения, но не в других.
  • После изменения значения даты и времени и его сохранения оно автоматически изменяется на другое значение.
  • Ввод даты перехода на летнее время приводит к отключению даты на один день или отгула на час.

Определение проблемы с сервером или клиентом

Приложения на основе модели — это веб-приложения. Они получают данные из облачной службы 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 г.
Time-Zone Independent дата и время; 15 октября 2023 г., 7:30
Time-Zone Independent Только дата 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 имеет поведение User Local . Таким образом, форматируемое значение отстает от необработанного значения на восемь часов.

{
    "@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 и сообщить о нем с помощью запроса в службу поддержки.

Попробуйте использовать другой часовой пояс

Чтобы узнать, вызывают ли корректировки часового пояса и летнего перехода непредвиденные значения, попробуйте изменить часовой пояс пользователя.

Существует два параметра, влияющих на часовые пояса в приложениях на основе модели:

  1. Часовой пояс в личных параметрах.
  2. Системный часовой пояс. Сведения о том, как изменить его, см. в соответствующей документации в Windows, Android, iOS или macOS.

Полезные сочетания:

  • Совпадите часовой пояс в личных параметрах с системным часовой поясом.
  • Используйте часовой пояс UTC.
  • Используйте часовой пояс с тем же смещением, но не отслеживает переход на летнее время.

Совет

Следующие методы предоставляют дополнительные сведения, чтобы упростить изучение проблем с датой и временем.

Измените формат "Только дата" на "Дата и время"

Если значение только даты отключено на день, полезно показать временную часть, чтобы узнать, может ли причина корректировки часового пояса. Вы можете временно изменить формат столбца напортале Power Apps или в обозревателе решений.

Не используйте 2-значные годы

2-значный год является неоднозначным. Например, 40 может означать 1940, 2040 или 2140. То, как система интерпретирует 2-значные годы, может и, скорее всего, изменится со временем.

Кроме того, трудно изучить ситуацию, когда не отображаются полные значения даты и времени. По этим причинам настоятельно рекомендуется использовать 4-значные годы, особенно при вводе дат.

Если вы не можете постоянно переключиться на 4-значный год, попробуйте временно устранить неполадки.

См. также

Поведение и формат столбца даты и времени