Anular serialización de DateTime para los parámetros de WebMethod de ASP.NET

Question

Estoy trabajando en la limpieza de un error en una gran base de código donde nadie estaba prestando atención a la hora local frente a la hora UTC.

Lo que queremos es una forma de ignorar globalmente la información de zona horaria en los objetos DateTime enviados ay desde nuestros servicios web ASP.NET. Tengo una solución para operaciones de recuperación. Los datos solo se devuelven en conjuntos de datos, y puedo buscar columnas DateTime y configurar el DateTimeMode en Unspecified. Eso resuelve mi problema para todos los datos pasados ​​dentro y fuera de un conjunto de datos.

Sin embargo, los objetos DateTime también se pasan a menudo directamente como parámetros a los métodos web. Me gustaría quitar cualquier información de zona horaria entrante. En lugar de buscar en nuestro código de cliente y usar DateTime.SpecifyKind (..) para establecer todos los valores de DateTime en Indefinido, me gustaría hacer algún tipo de anulación global de ASP.NET para monitorear los parámetros entrantes y eliminar la información de la zona horaria.

¿Es posible? ¿O hay otra forma más fácil de hacer lo que quiero hacer?

Solo para reiterar: no me importan las zonas horarias, todos están en la misma zona horaria. Pero un par de usuarios tienen máquinas mal configuradas, zonas horarias equivocadas, etc. Por lo tanto, cuando envían el 1 de julio de 2008, recibo el 30 de junio de 2008 a las 22:00:00 en el lado del servidor donde se está convirtiendo automáticamente de su hora local a la hora local del servidor.

Actualización: Otra posibilidad sería si fuera posible realizar un cambio en el lado del cliente del código .NET para alterar la forma en que los objetos DateTime con tipo 'No definido' se serializan.

Answer 1

He tratado esto a menudo en muchas aplicaciones, servicios y en diferentes plataformas (.NET, Java, etc.). Por favor, créame que NO desea las consecuencias a largo plazo de pretender que no le importa el huso horario. Después de perseguir muchos errores que son enormemente difíciles y costosos de solucionar, desearás haberte preocupado.

Por lo tanto, en lugar de despojar a la zona horaria, debe capturar la zona horaria correcta o forzar una zona horaria específica. Si puede hacerlo de forma razonable, arregle las diversas fuentes de datos para proporcionar un huso horario correcto. Si están fuera de su control, luego impúlselos a la zona horaria local del servidor o a UTC.

La convención general de la industria es forzar todo a UTC y establecer todos los relojes de hardware de producción en UTC (esto significa servidores, dispositivos de red como enrutadores, etc.). Luego debe traducir a/desde la zona horaria local del usuario en la interfaz de usuario.

Si lo corrige correctamente ahora, puede ser fácil y económico. Si intencionalmente lo rompes más porque crees que será más barato, entonces no tendrás excusas más adelante cuando tengas que desenmarañar el terrible desastre.

Tenga en cuenta que esto es similar al problema común con Strings: no existe el texto plano (una cadena sin codificación de caracteres) y no existe una fecha/hora normal (sin zona horaria) . Pretender lo contrario es la fuente de mucho dolor y angustia, y errores vergonzosos.

Answer 2

Bien, tengo una solución para esto, que depende del hecho de que realmente solo necesito la parte de fecha de DateTime. Adjunto esta propiedad a todas las fechas o parámetro DateTime en el sistema

<XmlElement(DataType:="date")> 

Esto cambia el WSDL generado para tener el tipo s: Fecha en lugar de s: fecha y hora. (Tenga en cuenta que simplemente tiene el tipo de.El parámetro del método NET es una fecha en lugar de un DateTime que NO logró esto). Entonces, el cliente ahora solo envía la porción de fecha del DateTime, no hay información de tiempo, no hay información de zona horaria.

Si alguna vez necesito enviar un valor de fecha y hora al servidor, tendré que usar alguna otra solución, por ejemplo, convertirla en un parámetro de cadena.

Answer 3

He tenido problemas con la información de la zona horaria también. El problema es que ya estoy proporcionando los campos de fecha y hora en UTC. Luego se produce la serialización y el desplazamiento local se convierte en parte de la fecha/hora. Las fechas/horas de nuestro proveedor en una zona horaria diferente fueron bastante desordenadas. Solucioné este problema utilizando la función de conversión de tsql en los campos de fecha y hora en mi declaración de selección que utilicé para completar mis conjuntos de datos. Esto convirtió los campos en una variable de cadena, que se traduce muy bien en un valor de fecha y hora automáticamente en el lado del cliente. Si solo desea pasar la fecha, puede usar el código 101 para proporcionar solo la fecha. Usé 126 para proporcionar la fecha y la hora exactamente cómo aparece en las columnas de mi base de datos, con la información de la zona horaria eliminada.