Los comportamientos de las fechas en Dynamics 365

Los comportamientos de las fechas en Dynamics 365

8 septiembre, 2020 eromerof 0

Para los que lleváis trabajando un tiempo con Dynamics 365 seguramente habéis tenido problemas con las fechas y su conversión. Como podéis ver en su documentación, en D365 las fechas tienen tres posibles comportamientos: Local del usuario, sólo fecha e independiente de la zona horaria. Vamos a explicar cada uno de ellos y cuándo elegirlo:

Local del usuario

Este es el valor por defecto en el que vienen los campos fecha y hora. ¿Qué significa? Que en la interfaz nos mostrará la hora convertida a nuestro horario y en base de datos en realidad guardará ese horario en UTC.

Por ejemplo: Imaginemos que estamos en UTC+2 y en un campo guardamos las 17:00. Cuando yo realice una consulta por código la API me devolverá la hora en UTC es decir, las 15:00. Si estás en un plugin tampoco intentes esto:

myDate.toLocalTime();

Ya que, el servidor donde se está ejecutando el plugin estará en UTC y lo único que conseguirás es una conversión de UTC a UTC.

Sólo fecha

¿Os ha pasado alguna vez que intentáis recuperar una fecha y os devuelve el día anterior? ¿Sabéis por qué es? Pues bien, el comportamiento sólo fecha viene a resolver esta casuística y es que cuando nosotros introducimos el valor de una fecha, nos devolverá la misma fecha y la hora será siempre las 12 de la noche. Por ejemplo: si introducimos el día 28 de agosto en la interfaz, la API nos retornará el 28 de agosto a las 12:00 AM.

Pero vamos a la duda que os he generado en el anterior párrafo.. ¿por qué nos devuelve el día anterior? Bien, si estamos en UTC+2 e introducimos en un campo fecha con comportamiento «Local del usuario» la fecha 28/08/2020 00:00.. el sistema interpretará que ese horario está en UTC+2. Sin embargo en base de datos cuando convierta a UTC guardará el 27/08/2020 22:00 que será el valor que nos devuelve la API. Si a una fecha cuya hora son las 12 de la noche le restamos dos horas.. nos vamos al día anterior…¿Tiene sentido, no?

Independiente de la zona horaria

En España tenemos un problema y es que tenemos distinto horario en verano y en invierno. Hace poco me veía con una problemática muy grave y es que necesitaba definir una planificación con unas horas pero claro.. dependiendo de si el usuario creaba esa planificación en horario de invierno o en horario de verano.. pues así me convertía las horas y claro… imagináos una hora más o una hora menos en el control de jornada de un trabajador..

Este comportamiento es muy parecido al de sólo fecha con la diferencia de que la hora no serán nunca las 12:00 AM, sino la hora exacta que hemos introducido en la interfaz sin ningún cambio de horario. Por ejemplo: Si en la interfaz introducimos 28/08/2020 17:00 entonces si tenemos este comportamiento la API nos devolverá 28/08/2020 17:00.

Conclusiones

  • Utiliza el método que más te convenga y evalúa bien las consecuencias
  • En el servidor de procesos de Dynamics 365 la hora local será UTC. Intentaré más adelante escribir una artículo para explicarte cómo convertir las horas en .Net
  • El comportamiento no se puede cambiar al no ser que sea «local del usuario». Una vez cambiado tendrás que borrar el campo y volver a crearlo.
  • Cuidado si son campos de alguna aplicación como Field Services. Es importante no cambiar el comportamiento de campos de este tipo de aplicaciones puesto que puede que hagan fallar procesos internos y rompas algo que es irreparable.

Si necesitas algo más ya sabes, contáctame por cualquiera de estas vías y tratamos de resolverlo lo mejor posible

Leave a Reply:

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *