c# - propiedades - ¿Cómo trata DateTimeOffset el horario de verano?
funciones de fecha en c# (1)
Sé que DateTimeOffset almacena una fecha / hora UTC y un desplazamiento. También sé por esta entrada de blog de MSDN que DateTimeOffset debe usarse para "Trabajar con horario de verano".
Lo que me cuesta entender es exactamente cómo funciona DateTimeOffset con el horario de verano. Según entiendo, poco de lo que hay, es que el horario de verano es una decisión política y no se puede inferir de una mera compensación. ¿Cómo puede ser que esta estructura sea compatible con DST si solo almacena un desplazamiento?
Supongo que puede haber una forma de usar la clase TimeZoneInfo junto con DateTimeOffset. ¿Como podría hacerlo?
Finalmente, ¿hay alguna forma mejor de lograr lo siguiente?
(He visto algunas publicaciones de Jon Skeet sobre Noda-Time pero supongo que todavía no está lista para la producción y no sé si se integraría bien en nuestra solución existente).
Aquí está nuestro escenario. El servidor es por desafortunados motivos heredados que se ejecutan en el Reino Unido. Tenemos clientes que comienzan a entrar en servicio desde Australia, que tiene múltiples zonas horarias. Otros países podrían entrar en funcionamiento en cualquier momento.
Tenemos un programador que se basa en el programador de Hardcodet (utiliza DateTimeOffset). Funciona muy bien. Sin embargo, en nuestra base de datos solo almacenamos datos suficientes para construir un objeto DateTime (ver a continuación) y en nuestro código de subclase y fontanería solo usamos DateTime, ya que originalmente solo apoyábamos a usuarios del Reino Unido.
Este programador es responsable de inmovilizar y movilizar el equipo de la planta. Por lo tanto, es vital que los eventos programados se ejecuten a la hora local ajustada por el horario de verano del usuario.
El usuario ingresa un horario en nuestro sitio web; Actualmente esto se almacena en la base de datos como un día de la semana, hora y minuto. Cuando se leen los datos, creamos un objeto DateTime para la próxima aparición de ese día, hora y minuto. Soy libre de alterar la estructura de la base de datos para almacenar adicionalmente un desplazamiento o zona horaria.
Cuando llega esa fecha y hora, el programador envía el comando (y vuelve a intentarlo por un tiempo). A continuación, vuelve a funcionar el mismo día y hora de la semana que viene (aunque para entonces el servicio ya habrá sido reciclado y el código se habrá ejecutado nuevamente).
TODO lo que necesito lograr es la activación de eventos programados en la fecha y hora local ajustada en la zona horaria para ese usuario que usa un programador que subclases de Hardcodet. Si DateTimeOffset realmente tiene DST, es posible que todo lo que deba hacer sea almacenar un offset y cambiar nuestro código de plomería para usar esta estructura, pero tengo la impresión de que no es tan simple como eso. (Es posible que podamos obtener la zona horaria actual desde la posición GPS de la planta, pero eso es una discusión para otro día :)).
DateTimeOffset sí no es realmente compatible con DST, pero TimeZoneInfo es. Un DateTimeOffset representa un instante fijo en el tiempo, por lo que llega a un DateTimeOffset través de algo que tiene en cuenta la zona horaria. En otras palabras, si pidiera un DateTimeOffset ahora en el Reino Unido, terminaría con algo con un desplazamiento de +1 hora desde UTC. Si pidiera un DateTimeOffset durante algún tiempo en diciembre en el Reino Unido, terminaría con algo con un desplazamiento de 0 horas desde UTC.
Si cambia su base de datos para incluir el desplazamiento y crea el DateTimeOffset partir del DateTime elegido por el usuario (que debería ser del tipo "no especificado") y su zona horaria, entonces eso le dará el desplazamiento correcto teniendo en cuenta el horario de verano.
Sin embargo, hay que tener en cuenta una cosa: si programo algo ahora para "2 años" y determina el desplazamiento ahora, ese desplazamiento puede no ser correcto en el futuro; por ejemplo, el gobierno podría cambiar cuando se aplique el horario de verano, y obviamente eso es todo. No va a cambiar lo que está almacenado en su base de datos.