En el post anterior, vimos como podemos averiguar la zona horaria del usuario que visita nuestra web, para así formatear una fecha con dicha zona horaria.

Sin embargo, hay una pequeña apreciación para el post anterior, que tiene que ver con los resultados de las búsquedas, devueltos por el buscador de SharePoint.

Si estás haciendo búsquedas de forma programática, y has conseguido sacar el campo que indica la fecha de creación del item (cosa que no es nada sencilla, y que os intentaré contar en otros posts), todavía os podéis llevar una sorpresa, si aplicáis lo que os contaba en el post anterior.

El problema está en que, como os decía, cuando el modelo de objetos te devuelve el DateTime de la fecha de creación de un SPListItem, ya le aplica la diferencia horaria con el servidor SharePoint. Es decir, si eran las 10:00h en UTC, y el servidor SharePoint está configurado en la zona horaria de España, el modelo de objetos te dirá que son las: 12:00 (España es UTC +2 en horario de verano).

Sin embargo, cuando trabajas con un ResultSet del modelo de objetos del buscador, y accedes a un campo DateTime, éste simpre te vendrá en formato UTC, por lo que, si luego nosotros, volvemos a aplicar:


Obtendremos un valor no deseado. Por ejemplo, si seguimos con el servidor de SharePoint configurado con la zona horaria de España, y el buscador, nos devuelve una fecha/hora: 25/05/2012 11:00h (que YA está en formato UTC), y volvemos a llamar a ToUniversalTime(), lo que obtenemos es: 25/05/2012 9:00h (-2h de la fecha incial, ya que el servidor está configurado en la zona horaria)

Para solucionar esto, es tan sencillo como no invocar a la función ToUniversalTime(). O bien, si ya tenemos encapsulada la función de formateo que recibe un DateTime, y que siempre llama al ToUniversalTime(), lo que podemos hacer es que, en el momento de invocar a nuestra función, pasamos el DateTime al tiempo local (esto es lo que digo que el SPListItem, ya hace de forma automática al recuperar la columna). Resumiendo:


Espero que os sirva.

Saludos!!