Solución de problemas de fecha y hora en aplicaciones controladas por modelos
Cuando los valores de fecha y hora están desactivados por un día o unas horas, puede deberse a ajustes de zona horaria o horario de verano. En este artículo se proporcionan sugerencias para solucionar problemas como:
- El campo Fecha y hora muestra el valor incorrecto.
- El valor Solo fecha muestra la fecha incorrecta para algunos usuarios y zonas horarias.
- El campo Fecha y hora muestra el valor correcto en algunas partes de la aplicación, pero no en otras.
- Después de cambiar un valor de fecha y hora y guardarlo, cambia automáticamente a un valor diferente.
- La entrada de una fecha de cambio de horario de verano da como resultado que la fecha esté desactivada un día o que la hora esté desactivada durante una hora.
Determinar si se trata de un problema de servidor o cliente
Las aplicaciones controladas por modelos son aplicaciones web. Obtienen datos del servicio en la nube de Dataverse (servidor). Los mismos datos pueden alimentar varias aplicaciones (clientes). Pueden producirse errores en el servidor o el cliente.
Si el valor de fecha y hora almacenado en el servidor es inesperado, es probable que aparezca incorrectamente en todas las aplicaciones, independientemente de la zona horaria del usuario o del sistema. Por lo tanto, comprobar el valor del servidor es un primer paso importante.
Comprobación de la configuración de la columna de fecha y hora
Dataverse admite diferentes comportamientos de ajuste de zona horaria para las columnas de fecha y hora (campos). Antes de solucionar problemas, es importante comprender las distintas partes de los valores de fecha y hora del proceso del sistema.
Compruebe las opciones de columna de fecha y hora en el portal de Power Apps o en el explorador de soluciones:
- Si tiene en cuenta la zona horaria de un usuario
- Si muestra la parte de tiempo del valor
Compruebe si el valor correcto está almacenado en el servidor.
Los valores de fecha y hora siempre se almacenan como UTC en el servidor. Puede ver el valor sin procesar en el servidor con una consulta de API web.
Esta es una consulta para obtener una columna de una fila (registro).
[Organization URI]/api/data/v9.2/<entity set name>(<row id>)?$select=<column name>
Los nombres de tabla y columna utilizados son nombres lógicos, no nombres para mostrar.
Sugerencia
Una manera fácil de encontrar el identificador de una fila es abrirla en una aplicación controlada por modelos. El identificador se puede encontrar en la dirección URL de la página.
En el ejemplo siguiente se obtiene la scheduledstart columna de la appointment tabla de la fila con el identificador d2862246-4763-ee11-8def-000d3a34118b.
https://myorg.crm.dynamics.com/api/data/v9.2/appointments(d2862246-4763-ee11-8def-000d3a34118b)?$select=scheduledstart
Si escribe esto en la barra de direcciones del explorador, se mostrará algo parecido a lo siguiente:
{
"@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"
}
Por lo tanto, el scheduledstart de es appointment 15 de octubre de 2023, 7:30 am. Al Z final indica que el valor está en UTC.
Supongamos que un usuario de la zona horaria UTC-8 ve esta columna en una aplicación controlada por modelos. Estos son los valores esperados para las distintas opciones de columna.
| Comportamiento de ajuste de zona horaria | Formato | Valor que se muestra en la aplicación |
|---|---|---|
| Local de usuario | Fecha y hora | 14 de octubre de 2023, 11:30 p.m. |
| Local de usuario | Solo fecha | 14 de octubre de 2023 |
| Time-Zone independiente | Fecha y hora | 15 de octubre de 2023, 7:30 am |
| Time-Zone independiente | Solo fecha | 15 de octubre de 2023 |
| Solo fecha | - | 15 de octubre de 2023 |
Si el valor que se muestra en la aplicación no se ajusta correctamente, es probable que sea un problema de cliente. Si el valor del servidor no es correcto para empezar, es probable que sea un problema del servidor.
Comprobación del valor con formato desde el servidor
Los ajustes de zona horaria y horario de verano se pueden realizar en el servidor o en la aplicación. Si la misma columna muestra un valor diferente en diferentes partes de la aplicación, es probable que algunas partes de la aplicación usen el valor con formato del servidor, mientras que otras realizan los ajustes en la aplicación.
Es probable que se trate de un problema. Antes de notificarlo, puede aislar si se trata de un problema de servidor o cliente comprobando el valor con formato del servidor.
Por ejemplo,
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 respuesta incluirá el valor ajustado por el servidor. En este ejemplo, el usuario está en la zona horaria UTC-8 y scheduledstart tiene el comportamiento Local del usuario . Por lo tanto, el valor con formato está ocho horas detrás del valor sin procesar.
{
"@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 este valor con formato es incorrecto, es un problema del servidor. Si es correcto, se trata de un problema de cliente.
Investigación de valores de servidor inesperados
Los posibles motivos para los valores de servidor inesperados son:
- Es posible que no haya configurado correctamente el comportamiento y el formato del ajuste de zona horaria.
- Las reglas de negocio y los flujos de trabajo que se ejecutan en el servidor pueden cambiar el valor antes o después de guardarlo. Dentro de una aplicación, los scripts de cliente pueden cambiar el valor antes de enviarlo al servidor para guardarlo.
Determinar si se trata de un problema de personalización o de producto
Las personalizaciones pueden dar lugar a un comportamiento inesperado. Los métodos siguientes pueden ayudar a descartar los problemas causados por las personalizaciones.
Deshabilitar scripts personalizados
Los scripts personalizados suelen causar problemas. Intente deshabilitarlos temporalmente.
Creación de una nueva columna de fecha y hora
La creación de una nueva columna de fecha y hora es la manera más sencilla de averiguar si el problema se debe a errores de configuración o personalizaciones como reglas de negocio. Lo ideal es usar una tabla y una aplicación diferentes.
Si la nueva columna funciona según lo esperado, es probable que sea un problema de personalización. Compare con la columna original para encontrar la diferencia.
Si la nueva columna tiene el mismo problema, podría ser un problema del producto. Puede crear una aplicación basada en modelos de reproducción de vainilla y notificarla a través de una solicitud de soporte técnico.
Pruebe con otra zona horaria
Para averiguar si los ajustes de zona horaria y horario de verano están causando valores inesperados, intente cambiar la zona horaria del usuario.
Hay dos configuraciones que afectan a las zonas horarias en aplicaciones controladas por modelos:
- Zona horaria en opciones personales.
- Zona horaria del sistema. Para obtener información sobre cómo cambiarlo, consulte la documentación correspondiente en Windows, Android, iOS o macOS.
Combinaciones útiles para probar:
- Coincide con la zona horaria de las opciones personales con la zona horaria del sistema.
- Use la zona horaria UTC.
- Use una zona horaria con el mismo desplazamiento, pero no observe el horario de verano.
Sugerencia
Los métodos siguientes proporcionan más detalles para facilitar la investigación de problemas de fecha y hora.
Cambie el formato "Solo fecha" a "Fecha y hora"
Si un valor de solo fecha está desactivado por un día, es útil mostrar la parte de hora para ver si los ajustes de zona horaria podrían ser la causa. Puede cambiar temporalmente el formato de columna en el portal de Power Apps o en el Explorador de soluciones.
No usar años de 2 dígitos
El año de 2 dígitos es ambiguo. Por ejemplo, 40 podría significar 1940, 2040 o 2140. La forma en que el sistema interpreta los años de 2 dígitos puede y probablemente cambiará con el tiempo.
También es difícil investigar cuándo no se muestran los valores de fecha y hora completos. Por estas razones, se recomienda encarecidamente usar años de 4 dígitos, especialmente cuando se escriben fechas.
Si no puede cambiar a 4 dígitos de forma permanente, inténtelo temporalmente para ayudar a solucionar problemas.