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
Desde muy joven he sido un apasionado por la tecnología pero no fue hasta hace algo más de 8 años que me presentaron a Dynamics 365 (para entonces Dynamics CRM) y ahora, junto con toda la power platform, nos hemos hecho muy amigos. Me encanta desarrollar hasta llegar a la forma más óptima y sencilla de realizar las cosas porque (como se dice) en la sencillez reside la elegancia siempre y cuando respete el estándar del producto.
Hola Enrique, primero que todo darte las gracias por este articulo tan interesante y muy útil. quisiera que me ayudaras a resolver esta duda, tengo una aplicacion de Sales D365 en la cual para la entidad de Order cree unos campos de tipo fecha y hora, los cuales se crearon incialmente con comportamiento local del usuario. Algunos usuarios al momento de abrir un resgistro de esa entidad en los campos mencionados les esta mostrando una fecha diferente, tal cual como el ejemplo que mencionaste arriba. En este caso lo ideal es que se mostrara la fecha que ingresaron en el campo al momento de la creación. según lo que acabas de explicar esto se resolvería cambiando el comportamiento a solo fecha y borrando el valor que hay en el campo y volverlo a crear. Mi pregunta es, ¿podría este cambio afectar algún proceso interno de la aplicación? cabe resaltar que se está manejando con dos cambientes (Desarrollo y Producción), primero se aplicaciría el cambio en el ambiente de desarrollo y luego se pasaría la solución al ambiente de producción.
Me ayudarías mucho aclarando esta duda. Muchas gracias de antemano.
Hola Angel,
Pues la respuesta es fácil. Si son campos personalizados puedes cambiarlo sin ningún problema, si son campos del sistema yo evitaría cambiarlo. Al cambiarlo debes revisar las dependencias que tienes sobre ese campo sobre los distintos procesos asociados y además debes revisar el javascript asociado (Para el javascript basta con hacer una búsqueda en tu repositorio de código). ¿En qué afectará? Básicamente que el sistema asume que la fecha siempre está en UTC y es la propia interfaz la que realiza el cambio de hora. Si cambiamos a local le estamos diciendo al sistema que esa hora siempre va a ser UTC y para la interfaz de usuario también se mostrará en UTC. A priori no debe suponer un problema pero revisa bien todos tus procesos asociados antes de dar el cambio definitivo. Una vez cambiado el comportamiento a local no podrás revertirlo por lo que, antes te recomiendo que lo pruebes en un entorno aislado de tu ALM.
Hola Enrique,
perfecto, muchas gracias por aclarar mi duda. Un abrazo.