lunes, septiembre 04, 2006

Caso de estudio

Ok, despues de investigar un poco... y hasta toparme con el mismo articulo con el que se topo Kamikaze, pues efectivamente, existe ese detalle! En realidad no es un problema del Framework, tampoco es problema de logica/programacion... asi esta diseñado y como no se le puede dar gusto a todos, pues algunos se presentan con estas situaciones no deseables, efectivamete todo el problema viene en la serializacion y deserializacion de DateTime... Un ejemplo bueno es una fecha de cumpleaños, donde solo te interesa la fecha y no la hora, muchos de nosotros no sabemos a que hora nacimos, ok, suponiendo ando de vacaciones en x lugar que tiene horario diferente al mi ciudad, y en ese viaje me doy de alta en una pagina importante para mi, y al darse de alta digo yo naci el 4 de Julio, haaay we.. bueno el caso es que cuando llego a mi ciudad y veo mis datos dice que naci el 3 de Julio, porque la convertir la hora  ami tiempo local y al hacer la resta de horas, pues me da 3 de Julio, el cual para mi es incorrecto... Ah solo es un ejemplo donde esto puede llevar a un comportamiento no deseado y no necesariamente mal (que nunca quize decir esta mal mi logica o esta mal el .net)

En cuanto a manejar todo en UTC, pues tambien tiene sus detalles, como dice el articulo, no es 100% confiable debido a los horarios de verano.. pero bueno es solo una hora la que se "pierde" en el universo y a lo mejor esto no afecta a la mayoria...

Bueno por ahorita mi posible solucion es implementar uno de los workarounds que se encuentran en varios articulos de la red...

Por cierto para mañana tengo otro caso de estudio (asi es como le llamo a los problemas)....

*********************************************************

Cuantas veces no hemos tenido broncas con resultados inesperados, o por lo meno inesperados para nosotros pero esperados para el sistema, jajajajajaja... bueno antes de ponerme a investigar a fondo aqui les dejo una pregunta para los dot neteros, a lo mejor y alguien ya se topo con eso y ya encontro una solucion:

Si tengo un webservice en un servidor (virtual o no virtual), y una base de datos en el mismo server, y ademas tengo un programa cliente que accesa a ese webservice y le pide datos de la DB...

Pues bien el detalle que surgio es el siguiente: Si en la PC donde se esta ejecutando el webservice tiene una zona horaria (digamos Eastern Time por ejemplo) diferente a la de la maquina cliente (digamos GMT-07 Chihuahua) pues me hace por ahi una conversion indeseada (por lo menos para mi) de las fechas... Pues resulta que si un programa cliente da de alta un registro con la pura fecha (sin el time) el cliente manda ese dato al server, el server lo guarda pero ajusta la fecha basado en su zona horaria, si el cliente manda una fecha digamos 14 de Sept, en la base de datos se guarda 15 de Sept, pero al leerlo el cliente pone 14 de Sept, como si todo estuviera muy bien... es decir al mandar una fecha por el cliente, el webservice la toma y automaticamente la convierte y la guarda en la DB "convertida", al leerla el cliente, el webservice lee los datos y los convierte y el cliente la lee como deberia de ser... pero que pasa si en el cliente ejecutas un query construido directamente en codigo (ej. select * from Socios where FechaIngreso = '09/14/2006'), pues ya no encuentra el registro en la DB y esto puede causar muchos dolores de cabeza...

Alguien sabe como decirle al .net, que no haga ninguna conversion.. si mando 9/15/2006 12:00:00 AM, que asi lo guarde en el server aunque este este en japon y viceversa, que si lee 9/15/2006 12:00:00 AM, asi lo ponga el cliente aunque este en una zona horaria distinta? o cual seria lo correcto en este caso para evitar algun problema parecido?

Bueno espero a esos dotneteros chuchos que yo se hay muchos por aqui :))

PD: Estoy utilizando .Net 1.1 y no me puedo migrar al 2.0, que ya resolvio este problema :(

No hay comentarios.: