Résoudre les problèmes de date et d’heure dans les applications pilotées par modèle
Lorsque les valeurs de date et d’heure sont désactivées par jour ou quelques heures, elles peuvent être provoquées par des ajustements de fuseau horaire ou d’été. Cet article fournit des conseils pour résoudre les problèmes tels que :
- Le champ Date et Heure affiche la valeur incorrecte.
- La valeur Date affiche uniquement la date incorrecte pour certains utilisateurs et fuseaux horaires.
- Le champ Date et Heure affiche la valeur correcte dans certaines parties de l’application, mais pas d’autres.
- Après avoir modifié une valeur de date et d’heure et l’avoir enregistré, elle passe automatiquement à une autre valeur.
- La saisie d’une date de basculement d’enregistrement d’été entraîne l’arrêt de la date d’un jour ou l’heure d’arrêt d’une heure.
Déterminer s’il s’agit d’un problème de serveur ou de client
Les applications basées sur des modèles sont des applications web. Ils obtiennent des données à partir du service cloud Dataverse (serveur). Les mêmes données peuvent alimenter plusieurs applications (clients). Des erreurs peuvent se produire sur le serveur ou le client.
Si la valeur de date et d’heure stockée sur le serveur est inattendue, elle apparaîtra probablement incorrectement dans toutes les applications, quel que soit le fuseau horaire utilisateur ou système. Par conséquent, la vérification de la valeur du serveur est une première étape importante.
Vérifier la configuration de la colonne date et heure
Dataverse prend en charge différents comportements d’ajustement de fuseau horaire pour les colonnes de date et d’heure (champs). Avant de résoudre les problèmes, il est important de comprendre comment différentes parties du processus système ont des valeurs de date et d’heure différentes.
Vérifiez les options de colonne de date et d’heure dans le portail Power Apps ou l’Explorateur de solutions :
- Indique s’il compte pour le fuseau horaire d’un utilisateur
- Indique s’il affiche la partie temporelle de la valeur
Vérifiez si la valeur correcte est stockée sur le serveur
Les valeurs de date et d’heure sont toujours stockées au format UTC sur le serveur. Vous pouvez afficher la valeur brute sur le serveur avec une requête d’API web.
Voici une requête pour obtenir une colonne pour une ligne (enregistrement).
[Organization URI]/api/data/v9.2/<entity set name>(<row id>)?$select=<column name>
Les noms de table et de colonne utilisés sont des noms logiques, et non des noms d’affichage.
Conseil
Un moyen simple de trouver l’ID d’une ligne consiste à l’ouvrir dans une application pilotée par modèle. L’ID se trouve dans l’URL de la page.
L’exemple suivant obtient la scheduledstart colonne de la appointment table pour la ligne avec l’ID d2862246-4763-ee11-8def-000d3a34118b.
https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart
L’entrée dans la barre d’adresses du navigateur affiche quelque chose comme suit :
{
"@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"
}
Par conséquent, le scheduledstart appointment 15 octobre 2023, 7h30. La Z fin indique que la valeur est au format UTC.
Supposons qu’un utilisateur dans le fuseau horaire UTC-8 affiche cette colonne dans une application pilotée par modèle. Il s’agit des valeurs attendues pour les différentes options de colonne.
| Comportement d’ajustement du fuseau horaire | Format | Valeur affichée dans l’application |
|---|---|---|
| Heure locale de l’utilisateur | Date et heure | 14 octobre 2023, 23h30 |
| Heure locale de l’utilisateur | Date uniquement | 14 octobre 2023 |
| Sans fuseau horaire | Date et heure | 15 octobre 2023, 7h30 |
| Sans fuseau horaire | Date uniquement | 15 octobre 2023 |
| Date uniquement | - | 15 octobre 2023 |
Si la valeur affichée dans l’application n’est pas ajustée correctement, il s’agit probablement d’un problème client. Si la valeur du serveur n’est pas correcte pour commencer, il s’agit probablement d’un problème de serveur.
Vérifier la valeur mise en forme à partir du serveur
Les ajustements du fuseau horaire et de l’enregistrement d’été peuvent être effectués sur le serveur ou dans l’application. Si la même colonne affiche une valeur différente dans différentes parties de l’application, il est probable que certaines parties de l’application utilisent la valeur mise en forme du serveur, tandis que d’autres effectuent les ajustements dans l’application.
Il s’agit probablement d’un problème. Avant de le signaler, vous pouvez isoler s’il s’agit d’un problème de serveur ou de client en vérifiant la valeur mise en forme du serveur.
Par exemple,
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"
La réponse inclut la valeur ajustée par le serveur. Dans cet exemple, l’utilisateur se trouve dans le fuseau horaire UTC-8 et scheduledstart a le comportement local de l’utilisateur. Par conséquent, la valeur mise en forme est de huit heures derrière la valeur brute.
{
"@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"
}
Si cette valeur mise en forme est incorrecte, il s’agit d’un problème de serveur. S’il est correct, il s’agit d’un problème client.
Examiner les valeurs inattendues du serveur
Les raisons possibles pour les valeurs de serveur inattendues sont les suivantes :
- Vous n’avez peut-être pas configuré le comportement d’ajustement du fuseau horaire et le format correct.
- Les règles d’entreprise et les flux de travail exécutés sur le serveur peuvent modifier la valeur avant ou après son enregistrement. Dans une application, les scripts clients peuvent modifier la valeur avant de l’envoyer au serveur pour l’enregistrement.
Déterminer s’il s’agit d’un problème de personnalisation ou d’un problème de produit
Les personnalisations peuvent entraîner un comportement inattendu. Les méthodes suivantes peuvent vous aider à exclure les problèmes causés par les personnalisations.
Désactiver des scripts personnalisés
Les scripts personnalisés provoquent fréquemment des problèmes. Essayez de les désactiver temporairement.
Créer une colonne de date et d’heure
La création d’une colonne de date et d’heure est le moyen le plus simple de déterminer si le problème est dû à des erreurs de configuration ou à des personnalisations telles que des règles métier. Dans l’idéal, utilisez une autre table et une autre application.
Si la nouvelle colonne fonctionne comme prévu, il s’agit probablement d’un problème de personnalisation. Comparez avec la colonne d’origine pour trouver la différence.
Si la nouvelle colonne présente le même problème, il peut s’agir d’un problème de produit. Vous pouvez créer une application basée sur un modèle de reproduction vanille et la signaler via une demande de support.
Essayer un autre fuseau horaire
Pour savoir si les ajustements de fuseau horaire et d’enregistrement d’été provoquent des valeurs inattendues, essayez de modifier le fuseau horaire de l’utilisateur.
Il existe deux paramètres qui affectent les fuseaux horaires dans les applications basées sur des modèles :
- Fuseau horaire dans les options personnelles.
- Fuseau horaire système. Pour plus d’informations sur la façon de le modifier, consultez la documentation correspondante dans Windows, Android, iOS ou macOS.
Combinaisons utiles à essayer :
- Mettre en correspondance le fuseau horaire dans les options personnelles avec le fuseau horaire système.
- Utilisez le fuseau horaire UTC.
- Utilisez un fuseau horaire avec le même décalage, mais n’observe pas l’enregistrement de l’été.
Conseil
Les méthodes suivantes fournissent plus de détails pour faciliter l’examen des problèmes de date et d’heure.
Remplacez le format « Date uniquement » par « Date et heure »
Si une valeur date seule est désactivée par jour, il est utile d’afficher la partie horaire pour voir si les ajustements de fuseau horaire peuvent être la cause. Vous pouvez modifier temporairement le format de colonne dans le portail Power Apps ou l’Explorateur de solutions.
N’utilisez pas d’années à 2 chiffres
L’année à 2 chiffres est ambiguë. Par exemple, 40 peuvent signifier 1940, 2040 ou 2140. La façon dont le système interprète les années à 2 chiffres et change probablement au fil du temps.
Il est également difficile d’examiner quand les valeurs de date et d’heure complètes ne sont pas affichées. Pour ces raisons, il est fortement recommandé d’utiliser des années à 4 chiffres, en particulier lors de l’entrée de dates.
Si vous ne pouvez pas passer définitivement à 4 chiffres, essayez-le temporairement pour vous aider à résoudre les problèmes.