Solucionar problemas de fecha y hora en aplicaciones basadas en modelos
Cuando los valores de fecha y hora están desactivados por un día o unas pocas 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 De fecha solo 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.
- Al escribir una fecha de cambio de horario de verano, la fecha está desactivada un día o la hora que está desactivada en 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 (servidor) de Dataverse. Los mismos datos pueden alimentar varias aplicaciones (clientes). Los errores pueden producirse 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 del usuario o la zona horaria 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 columnas de fecha y hora (campos). Antes de solucionar problemas, es importante comprender cómo diferentes 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
- Indica 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 para una fila (registro).
[Organization URI]/api/data/v9.2/<entity set name>(<row id>)?$select=<column name>
Los nombres de tabla y columna usados son nombres lógicos, no nombres para mostrar.
Sugerencia
Una manera fácil de encontrar el identificador de una fila es abrirlo 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 para 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
Al escribir esto en la barra de direcciones del explorador se mostrará algo parecido al 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 el 15 de appointment octubre de 2023, 7:30 am. Al Z final se 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 | Format | Valor que se muestra en la aplicación |
|---|---|---|
| Local del usuario | Fecha y hora | 14 de octubre de 2023, 23:30 horas |
| Local del usuario | Solo fecha | 14 de octubre de 2023 |
| Independiente de la zona horaria | Fecha y hora | 15 de octubre de 2023, 7:30 am |
| Independiente de la zona horaria | 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 es incorrecto para comenzar, es probable que sea un problema de servidor.
Compruebe el valor con formato del 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 distintas 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.
Esto es probable que se produzca 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 es de ocho horas detrás del valor sin formato.
{
"@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, se trata de un problema de servidor. Si es correcto, se trata de un problema de cliente.
Investigación de valores de servidor inesperados
Las posibles razones de los valores de servidor inesperados son:
- Es posible que no haya configurado correctamente el comportamiento de ajuste de zona horaria y el formato.
- 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 provocar un comportamiento inesperado. Los métodos siguientes pueden ayudar a descartar problemas causados por personalizaciones.
Deshabilitación de 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 fácil de averiguar si el problema se debe a errores de configuración o personalizaciones como las reglas de negocio. Idealmente, use una tabla y una aplicación diferentes.
Si la nueva columna funciona según lo previsto, 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 de producto. Puede crear una aplicación controlada por modelos de vainilla y notificarla a través de una solicitud de soporte técnico.
Prueba de una zona horaria diferente
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 cambiarla, consulte la documentación correspondiente en Windows, Android, iOS o macOS.
Combinaciones útiles para probar:
- Coincide con la zona horaria en 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, resulta útil mostrar la parte de tiempo 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 use 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 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 al escribir fechas.
Si no puede cambiar a años de 4 dígitos de forma permanente, pruébelo temporalmente para ayudar a solucionar problemas.