Pregunta Horario de verano y mejores prácticas de zonas horarias [cerrado]


Espero hacer de esta pregunta y las respuestas la guía definitiva para lidiar con el horario de verano, en particular para lidiar con los cambios reales.

Si tiene algo que agregar, por favor

Muchos sistemas dependen de mantener la hora exacta, el problema es con los cambios en el tiempo debido a los ahorros de luz diurna: mover el reloj hacia adelante o hacia atrás.

Por ejemplo, uno tiene reglas comerciales en un sistema de toma de pedidos que dependen de la hora del pedido; si el reloj cambia, las reglas podrían no ser tan claras. ¿Cómo debe persistir el tiempo de la orden? Por supuesto, hay un sinfín de escenarios, este es simplemente ilustrativo.

  • ¿Cómo ha lidiado con el problema del horario de verano?
  • ¿Qué suposiciones son parte de su solución? (buscando contexto aquí)

Tan importante, si no más:

  • ¿Qué intentaste que no funcionó?
  • ¿Por qué no funcionó?

Me interesaría la programación, el sistema operativo, la persistencia de datos y otros aspectos pertinentes del problema.

Las respuestas generales son geniales, pero también me gustaría ver detalles, especialmente si solo están disponibles en una plataforma.


1885


origen


Respuestas:



Resumen de respuestas y otros datos: (por favor agregue el suyo)

Hacer:

  • Siempre que te refieras a un momento exacto en el tiempo, persiste el tiempo de acuerdo con un estándar unificado que no se ve afectado por el horario de verano. (GMT y UTC son equivalentes a este respecto, pero se prefiere utilizar el término UTC. Tenga en cuenta que UTC también se conoce como zulú o Z hora.)
  • Si, por el contrario, elige persistir un tiempo utilizando un valor de tiempo local, incluya la compensación de tiempo local para esta hora particular de UTC (este desplazamiento puede cambiar a lo largo del año), de modo que la marca de tiempo pueda interpretarse más adelante sin ambigüedad.
  • En algunos casos, es posible que necesite almacenar ambos la hora UTC y la hora local equivalente. A menudo, esto se hace con dos campos separados, pero algunas plataformas admiten una datetimeoffset tipo que puede almacenar ambos en un solo campo.
  • Al almacenar las marcas de tiempo como un valor numérico, use Tiempo de Unix - que es la cantidad de segundos enteros desde 1970-01-01T00:00:00Z (excluyendo segundos intercalares). Si necesita una mayor precisión, utilice milisegundos en su lugar. Este valor siempre debe basarse en UTC, sin ningún ajuste de zona horaria.
  • Si luego necesita modificar la marca de tiempo, incluya la identificación de la zona horaria original para que pueda determinar si la compensación puede haber cambiado desde el valor original registrado.
  • Al programar eventos futuros, generalmente se prefiere la hora local en lugar de la UTC, ya que es común que la compensación cambie. Ver respuestay entrada en el blog.
  • Al almacenar fechas completas, como cumpleaños y aniversarios, no convierta a UTC ni a ninguna otra zona horaria.
    • Cuando sea posible, almacene en un tipo de datos de fecha solamente que no incluya una hora del día.
    • Si dicho tipo no está disponible, asegúrese de ignorar siempre la hora del día cuando interpreta el valor. Si no puede estar seguro de que se ignorará la hora del día, elija 12:00 mediodía, en lugar de 00:00 medianoche, como una hora representativa más segura ese día.
  • Recuerde que las compensaciones de zona horaria no son siempre un número entero de horas (por ejemplo, el horario estándar de India es UTC + 05: 30, y Nepal usa UTC + 05: 45).
  • Si usa Java, use java.time para Java 8, o uso Joda Time para Java 7 o inferior.
  • Si usas .RED, Considere usar Hora de Noda.
  • Si usa .NET sin tiempo Noda, considere que DateTimeOffset a menudo es una mejor opción que DateTime.
  • Si usa Perl, use Fecha y hora.
  • Si usa Python, use pytz o dateutil.
  • Si usa JavaScript, use moment.js con el momento-timezone extensión.
  • Si usa PHP> 5.2, use las conversiones de zonas horarias nativas proporcionadas por DateTimey DateTimeZone clases Tenga cuidado al usar DateTimeZone::listAbbreviations() - Ver respuesta. Para mantener PHP actualizado con datos de Olson, instálelo periódicamente el timezonedb Paquete PECL; Ver respuesta.
  • Si usa C ++, asegúrese de usar una biblioteca que utiliza correctamente implementa el Base de datos de zona horaria IANA. Éstas incluyen cctz, UCIy Biblioteca "tz" de Howard Hinnant.
    • No utilice Aumentar para las conversiones de zona horaria. Mientras su API afirma que es compatible con identificadores estándar IANA (también conocidos como "zoneinfo"), crudamente los mapea a los datos de estilo POSIX, sin tener en cuenta el rico historial de cambios que cada zona puede haber tenido. (Además, el archivo se ha quedado sin mantenimiento).
  • La mayoría de las reglas comerciales usan tiempo civil, en lugar de UTC o GMT. Por lo tanto, planee convertir las marcas de tiempo UTC en un huso horario local antes de aplicar la lógica de la aplicación.
  • Recuerde que las zonas horarias y los desplazamientos no son fijos y pueden cambiar. Por ejemplo, históricamente, EE. UU. Y el Reino Unido utilizaron las mismas fechas para "adelantarse" y "retroceder". Sin embargo, en 2007, los EE. UU. Cambiaron las fechas en las que cambian los relojes. Esto significa que, durante 48 semanas del año, la diferencia entre el horario de Londres y el horario de Nueva York es de 5 horas y durante 4 semanas (3 en la primavera, 1 en el otoño) es de 4 horas. Tenga en cuenta elementos como este en cualquier cálculo que involucre varias zonas.
  • Considere el tipo de tiempo (tiempo del evento real, tiempo de transmisión, tiempo relativo, hora histórica, tiempo recurrente) qué elementos (marca de tiempo, desplazamiento de zona horaria y nombre de zona horaria) necesita almacenar para la recuperación correcta - consulte "Tipos de tiempo" en esta respuesta.
  • Mantenga sincronizados su sistema operativo, la base de datos y los archivos tzdata de la aplicación, entre ellos y el resto del mundo.
  • En los servidores, establezca relojes de hardware y relojes del sistema operativo en UTC en lugar de una zona horaria local.
  • Independientemente de la viñeta anterior, el código del lado del servidor, incluidos los sitios web, debe Nunca espera que la zona horaria local del servidor sea algo en particular. Ver respuesta.
  • Prefiere trabajar con husos horarios caso por caso en el código de la aplicación, en lugar de hacerlo de forma global a través de la configuración de archivos de configuración o valores predeterminados.
  • Utilizar NTP servicios en todos los servidores.
  • Si usas FAT32, recuerde que las marcas de tiempo se almacenan en la hora local, no en UTC.
  • Cuando se trata de eventos recurrentes (programa de televisión semanal, por ejemplo), recuerde que la hora cambia con horario de verano y será diferente en las zonas horarias.
  • Siempre consulte valores de fecha y hora como límite inferior inclusivo, límite superior exclusivo (>=, <)

No hacer:

  • No confunda una "zona horaria", como America/New_York con un "desplazamiento de zona horaria", como -05:00. Son dos cosas diferentes. Ver la etiqueta de la zona horaria wiki.
  • No use JavaScript Date objeto para realizar cálculos de fecha y hora en navegadores web antiguos, como ECMAScript 5.1 y versiones anteriores un defecto de diseño que puede usar el horario de verano incorrectamente. (Esto se corrigió en ECMAScript 6/2015).
  • Nunca confíes en el reloj del cliente. Puede ser incorrecto.
  • No le diga a la gente "siempre use UTC en todas partes". Este consejo generalizado es miope de varios escenarios válidos que se describen anteriormente en este documento. En su lugar, use la referencia de tiempo apropiada para los datos con los que está trabajando. (Marcando la hora puede usar UTC, pero la programación de tiempo futuro y los valores de solo la fecha no deberían).

Pruebas:

  • Al realizar la prueba, asegúrese de probar países en el oeste, este, norte y Del Sur hemisferios (de hecho en cada cuarto del globo, entonces 4 regiones), con DST en progreso y no (da 8), y un país que no usa DST (otros 4 para cubrir todas las regiones, haciendo 12 en total).
  • Probar la transición de DST, es decir, cuando se encuentre actualmente en verano, seleccione un valor de tiempo de invierno.
  • Probar casos de límites, como una zona horaria UTC + 12, con horario de verano, con la hora local UTC + 13 en verano e incluso lugares que son UTC + 13 en invierno
  • Pruebe todas las bibliotecas y aplicaciones de terceros y asegúrese de que manejan correctamente los datos de zona horaria.
  • Pruebe las zonas horarias de media hora, al menos.

Referencia:

Otro:

  • Presiona a tu representante para que termine con la abominación que es DST. Siempre podemos esperar ...
  • Lobby para Hora estándar de la tierra

802



No estoy seguro de lo que puedo agregar a las respuestas anteriores, pero aquí hay algunos puntos de mi parte:

Tipos de veces

Hay cuatro momentos diferentes que debes considerar:

  1. Hora del evento: por ejemplo, el momento en que ocurre un evento deportivo internacional, o una coronación / muerte / etc. Esto depende de la zona horaria del evento y no del espectador.
  2. Tiempo de televisión: por ejemplo, un programa de TV en particular se emite a las 9 p. M., Hora local, en todo el mundo. Importante al pensar en publicar los resultados (por ejemplo, American Idol) en su sitio web
  3. Tiempo relativo: por ejemplo: esta pregunta tiene un cierre de recompensa abierta en 21 horas. Esto es fácil de mostrar
  4. Tiempo recurrente: por ejemplo: un programa de televisión está todos los lunes a las 9 p.m., incluso cuando cambia el horario de verano.

También hay tiempo histórico / alternativo. Estos son molestos porque no pueden mapear a la hora estándar. Ejemplo: fechas julianas, fechas según un calendario lunar en Saturno, el calendario klingon.

Almacenar las marcas de tiempo de inicio / fin en UTC funciona bien. Para 1, necesita un nombre de zona horaria del evento + desplazamiento almacenado junto con el evento. Para 2, necesita un identificador de hora local almacenado con cada región y un nombre de zona horaria local + desplazamiento almacenado para cada espectador (es posible obtener esto de la IP si está en una crisis). Para 3, almacenar en segundos UTC y sin necesidad de zonas horarias. 4 es un caso especial de 1 o 2 dependiendo de si se trata de un evento global o local, pero también necesita almacenar un Creado en marca de tiempo para que pueda saber si una definición de zona horaria cambió antes o después de que se creó este evento. Esto es necesario si necesita mostrar datos históricos.

Tiempos de almacenamiento

  • Guarde siempre el tiempo en UTC
  • Convertir a la hora local en la pantalla (local definido por el usuario que mira los datos)
  • Al almacenar una zona horaria, necesita el nombre, la marca de tiempo y el desplazamiento. Esto es necesario porque los gobiernos a veces cambian el significado de sus zonas horarias (por ejemplo: el gobierno de EE. UU. Cambió las fechas del horario de verano) y su aplicación necesita manejar las cosas con elegancia ... ej .: la marca de tiempo exacta cuando los episodios de LOST mostraron antes y después de las reglas de DST cambiado

Compensaciones y nombres

Un ejemplo de lo anterior sería:

El juego de finales de la copa mundial de fútbol   sucedido en Sudáfrica (UTC + 2 - SAST)   el 11 de julio de 2010 a las 19:00 UTC.

Con esta información, podemos determinar históricamente la hora exacta en que tuvieron lugar las finales de la WCS de 2010, incluso si cambia la definición de la zona horaria sudafricana, y ser capaz de mostrar eso a los espectadores en su zona horaria local en el momento en que consultan la base de datos.

Hora del sistema

También necesita mantener sus archivos tzdata de sistema operativo, base de datos y aplicaciones sincronizados, tanto entre sí como con el resto del mundo, y realizar pruebas exhaustivas al realizar la actualización. No es extraño que una aplicación de terceros de la que dependa no manejara correctamente un cambio de TZ.

Asegúrese de que los relojes de hardware estén configurados en UTC, y si está ejecutando servidores en todo el mundo, asegúrese de que sus sistemas operativos estén configurados para usar UTC también. Esto se hace evidente cuando necesita copiar archivos de registro de apache girados por hora desde servidores en múltiples zonas horarias. Ordenarlos por nombre de archivo solo funciona si todos los archivos se nombran con la misma zona horaria. También significa que no tiene que hacer la fecha matemática en su cabeza cuando pasa de una caja a otra y necesita comparar las marcas de tiempo.

Además, ejecute ntpd en todos los cuadros.

Clientela

Nunca confíe en la marca de tiempo que obtiene de una máquina cliente como válida. Por ejemplo, la Fecha: encabezados HTTP, o un javascript Date.getTime() llamada. Estos están bien cuando se usan como identificadores opacos, o al hacer matemática de fecha durante una sola sesión en el mismo cliente, pero no intente hacer una referencia cruzada de estos valores con algo que tenga en el servidor. Sus clientes no ejecutan NTP, y pueden no tener necesariamente una batería en funcionamiento para su reloj BIOS.

Trivialidades

Finalmente, los gobiernos a veces hacen cosas muy raras:

La hora estándar en los Países Bajos era   exactamente 19 minutos y 32.13 segundos   antes de UTC por ley de 1909-05-01   hasta 1937-06-30. Este huso horario   no se puede representar exactamente usando   el formato HH: MM.

Ok, creo que he terminado.


288



Este es un problema importante y sorprendentemente difícil. La verdad es que no existe un estándar completamente satisfactorio para el tiempo persistente. Por ejemplo, el estándar SQL y el formato ISO (ISO 8601) claramente no son suficientes.

Desde el punto de vista conceptual, uno generalmente trata con dos tipos de datos de fecha y hora, y es conveniente distinguirlos (los estándares anteriores no): "tiempo físico"y"tiempo civil".

Un instante "físico" de tiempo es un punto en la línea de tiempo universal continua con la que trata la física (ignorando la relatividad, por supuesto). Este concepto puede codificarse adecuadamente, persistir en UTC, por ejemplo (si puede ignorar los segundos intercalares).

Un tiempo "civil" es una especificación de fecha y hora que sigue las normas civiles: un punto de tiempo está completamente especificado por un conjunto de campos de fecha y hora (Y, M, D, H, MM, S, FS) más un TZ (especificación de zona horaria) (también un "calendario", en realidad, pero supongamos que restringimos la discusión al calendario gregoriano). Una zona horaria y un calendario conjuntamente permiten (en principio) mapear de una representación a otra. Pero los instantes de tiempo civil y físico son fundamentalmente diferentes tipos de magnitudes, y deben mantenerse conceptualmente separados y tratados de manera diferente (una analogía: matrices de bytes y cadenas de caracteres).

El problema es confuso porque hablamos de estos tipos de eventos indistintamente, y porque los tiempos civiles están sujetos a cambios políticos. El problema (y la necesidad de distinguir estos conceptos) se vuelve más evidente para los eventos en el futuro. Ejemplo (tomado de mi discusión aquí.

John registra en su calendario un recordatorio de algún evento en fecha y hora 2019-Jul-27, 10:30:00, TZ =Chile/Santiago, (que ha compensado GMT-4, por lo tanto, corresponde a UTC 2019-Jul-27 14:30:00) Pero algún día en el futuro, el país decide cambiar la compensación de TZ a GMT-5.

Ahora, cuando llegue el día ... ¿debería ese recordatorio disparar a

UN) 2019-Jul-27 10:30:00 Chile/Santiago  = UTC time 2019-Jul-27 15:30:00 ?

o

SEGUNDO) 2019-Jul-27 9:30:00 Chile/Santiago  = UTC time 2019-Jul-27 14:30:00 ?

No hay una respuesta correcta, a menos que uno sepa lo que John conceptualmente quiso decir cuando le dijo al calendario "Por favor llámame a 2019-Jul-27, 10:30:00 TZ=Chile/Santiago".

¿Quería decir "fecha civil" ("cuando los relojes en mi ciudad dicen 10:30 ")? En ese caso, A) es la respuesta correcta.

¿O quiso decir un "instante físico de tiempo", un punto en el continuo línea de tiempo de nuestro universo, por ejemplo, "cuando el próximo eclipse solar sucede ". En ese caso, la respuesta B) es la correcta.

Algunas API de fecha / hora obtienen esta distinción: entre ellas, Jodatime, que es la base de la próxima (tercera) API Java DateTime (JSR 310).


81



Haga una clara separación arquitectónica de las preocupaciones: para saber exactamente qué nivel interactúa con los usuarios, y tiene que cambiar la fecha / hora para / desde la representación canónica (UTC). La fecha y hora no UTC es la presentación (sigue la zona horaria local de los usuarios), La hora UTC es modelo (sigue siendo único para niveles intermedios y medios).

También, decida cuál es su audiencia real, qué no tiene que servir y dónde dibuja la línea. No toque calendarios exóticos a menos que realmente tenga clientes importantes allí y luego considere servidores para el usuario separados solo para esa región.

Si puede adquirir y mantener la ubicación del usuario, use la ubicación para la conversión sistemática de fecha y hora (por ejemplo .NET culture o una tabla SQL) pero brinde una manera para que el usuario final seleccione las anulaciones si la fecha-hora es crítica para sus usuarios.

Si hay obligaciones históricas de auditoría involucrado (como decir exactamente cuándo Jo en AZ pagó una factura hace 2 años en septiembre) luego mantenga tanto UTC como hora local para el registro (sus tablas de conversión cambiarán en el transcurso del tiempo).

Defina la zona horaria referencial de tiempo para los datos que se envían a granel - como archivos, servicios web, etc. Supongamos que la empresa de la Costa Este tiene un centro de datos en CA; debe preguntar y saber qué usan como estándar en lugar de asumir uno u otro.

No confíe en los desplazamientos de zona horaria incrustados en la representación textual de la fecha y hora no acepte analizar y seguirlos. En cambio, siempre solicite que la zona horaria y / o zona de referencia se definan explícitamente. Puede recibir fácilmente tiempo con compensación de PST, pero el tiempo es en realidad EST ya que ese es el tiempo de referencia del cliente y los registros fueron simplemente exportados a un servidor que está en PST.


53



Usted necesita saber sobre Olson base de datos tz, que está disponible desde ftp://elsie.nci.nih.gov/pub  http://iana.org/time-zones/. Se actualiza varias veces al año para lidiar con los cambios a menudo de último momento en cuándo (y si) para cambiar entre el invierno y el verano (horario estándar y horario de verano) en diferentes países del mundo. En 2009, el último lanzamiento fue en 2009; en 2010, fue 2010n; en 2011, fue 2011n; a fines de mayo de 2012, el lanzamiento fue 2012c. Tenga en cuenta que existe un conjunto de códigos para administrar los datos y los datos de la zona horaria en sí, en dos archivos separados (tzcode20xxy.tar.gz y tzdata20xxy.tar.gz). Tanto el código como los datos están en el dominio público.

Esta es la fuente de nombres de zona horaria como America / Los_Angeles (y sinónimos como US / Pacific).

Si necesita realizar un seguimiento de las diferentes zonas, entonces necesita la base de datos Olson. Como otros han aconsejado, también desea almacenar los datos en un formato fijo (generalmente UTC es el elegido) junto con un registro del huso horario en el que se generaron los datos. Es posible que desee distinguir entre el desplazamiento de UTC en el momento y el nombre de la zona horaria; eso puede marcar la diferencia más tarde. Además, saber que actualmente es 2010-03-28T23: 47: 00-07: 00 (EE. UU./Pacífico) puede o no ayudarlo a interpretar el valor 2010-11-15T12: 30, que se presume está especificado en PST ( Hora estándar del Pacífico) en lugar de PDT (horario de verano del Pacífico).

Las interfaces estándar de la biblioteca C no son tremendamente útiles con este tipo de cosas.


Los datos de Olson se han movido, en parte porque A D Olson se jubilará pronto, y en parte porque hubo una demanda (ahora desestimada) contra los mantenedores por infracción de derechos de autor. La base de datos de zona horaria ahora se gestiona bajo los auspicios de IANA, la Autoridad de números asignados de Internet, y hay un enlace en la página principal para 'Base de datos de zona horaria'. La lista de correo de discusión es ahora tz@iana.org; la lista de anuncios es tz-announce@iana.org.


38



En general, incluye la compensación de tiempo local (incluido el desplazamiento DST) en las marcas de tiempo almacenadas: UTC solo no es suficiente si luego desea mostrar la marca de tiempo en su zona horaria original (y la configuración de DST).

Tenga en cuenta que el desplazamiento no siempre es un número entero de horas (por ejemplo, el horario estándar indio es UTC + 05: 30).

Por ejemplo, los formatos adecuados son una tupla (tiempo de Unix, desplazamiento en minutos) o ISO 8601.


24



Cruzar el límite de "tiempo de la computadora" y "tiempo de la gente" es una pesadilla. El principal es que no hay ningún tipo de estándar para las reglas que rigen las zonas horarias y los horarios de verano. Los países son libres de cambiar su zona horaria y las reglas de horario de verano en cualquier momento, y lo hacen.

Algunos países, p. Israel, Brasil, decide cada año cuándo tener sus horarios de verano, por lo que es imposible saber de antemano cuándo (si) el horario de verano entrará en vigencia. Otros tienen reglas fijas (ish) sobre cuándo está vigente el horario de verano. Otros países no usan DST como todos.

Las zonas horarias no tienen que ser diferencias de horas completas desde GMT. Nepal es +5.45. Incluso hay zonas horarias que son +13. Eso significa que:

SUN 23:00 in Howland Island (-12)
MON 11:00 GMT 
TUE 00:00 in Tonga (+13)

son todos al mismo tiempo, ¡pero 3 días diferentes!

Tampoco hay un estándar claro sobre las abreviaturas para las zonas horarias, y cómo cambian en el horario de verano, por lo que terminas con cosas como esta:

AST Arab Standard Time     UTC+03
AST Arabian Standard Time  UTC+04
AST Arabic Standard Time   UTC+03

El mejor consejo es mantenerse alejado de los horarios locales tanto como sea posible y apegarse a UTC donde pueda. Solo conviértase a las horas locales en el último momento posible.

Al realizar las pruebas, asegúrese de realizar pruebas en países de los hemisferios occidental y oriental, con el horario de verano en progreso y no, y en un país que no utiliza el horario de verano (6 en total).


22



Para PHP:

La clase DateTimeZone en PHP> 5.2 ya está basada en el DB Olson que otros mencionan, por lo que si estás haciendo conversiones de zona horaria en PHP y no en el DB, estás exento de trabajar con los archivos Olson (difíciles de entender).

Sin embargo, PHP no se actualiza con tanta frecuencia como el DB de Olson, por lo que el simple hecho de utilizar las conversiones de zona horaria de PHP puede dejarle información desactualizada de DST e influir en la exactitud de sus datos. Si bien no se espera que esto ocurra con frecuencia, puede suceder, y será suceder si tiene una gran base de usuarios en todo el mundo.

Para lidiar con el problema anterior, use el paquete timezonedb pecl, esa es la función de actualizar los datos de la zona horaria de PHP. Instale este paquete con la frecuencia que se actualiza. (No estoy seguro de si las actualizaciones de estos paquetes siguen exactamente las actualizaciones de Olson, pero parece que se actualizan en una frecuencia que al menos está muy cerca de las actualizaciones de Olson).


18



Si su diseño puede acomodarlo, ¡evite la conversión de tiempo local todos juntos! 

Sé que esto puede parecer una locura, pero piense en UX: los usuarios procesan fechas cercanas, relativas (hoy, ayer, el próximo lunes) más rápido que las fechas absolutas (2010.09.17, viernes 17 de septiembre) en un vistazo. Y cuando lo piensas más, la precisión de las zonas horarias (y DST) es más importante cuanto más cerca esté la fecha now(), por lo que si puede expresar fechas / fechas en un formato relativo durante +/- 1 o 2 semanas, el resto de las fechas puede ser UTC y no importará demasiado para el 95% de los usuarios.

De esta forma, puede almacenar todas las fechas en UTC y hacer las comparaciones relativas en UTC y simplemente mostrar las fechas UTC del usuario fuera de su Umbral de fecha relativa.

Esto también se puede aplicar a la entrada del usuario también (pero generalmente de una manera más limitada). Seleccionar de un menú desplegable que solo tiene {Ayer, Hoy, Mañana, Lunes siguiente, Jueves siguiente} es mucho más simple y fácil para el usuario que un selector de fecha. Los selectores de fecha son algunos de los componentes más inductores de dolor en el llenado de formularios. Por supuesto, esto no funcionará en todos los casos, pero se puede ver que solo se necesita un poco de diseño inteligente para hacerlo muy poderoso.


15



Si bien no lo he probado, una aproximación a los ajustes de zona horaria que encontraría convincente sería la siguiente:

  1. Almacenar todo en UTC.

  2. Crea una mesa TZOffsets con tres columnas: RegionClassId, StartDateTime y OffsetMinutes (int, en minutos).

En la tabla, almacena una lista de fechas y horas cuando el horario local cambió, y por cuánto. La cantidad de regiones en la tabla y el número de fechas dependerán del rango de fechas y áreas del mundo que necesite para respaldar. Piense en esto como si fuera una fecha "histórica", aunque las fechas deberían incluir el futuro en algún límite práctico.

Cuando necesite calcular la hora local de cualquier hora UTC, simplemente haga esto:

SELECT DATEADD('m', SUM(OffsetMinutes), @inputdatetime) AS LocalDateTime
FROM   TZOffsets
WHERE  StartDateTime <= @inputdatetime
       AND RegionClassId = @RegionClassId;

Es posible que desee guardar en la memoria caché esta tabla en su aplicación y utilizar LINQ u otros medios similares para realizar las consultas en lugar de acceder a la base de datos.

Esta información puede ser extraída del base de datos tz de dominio público.

Ventajas y notas a pie de página de este enfoque:

  1. No hay reglas cocidas en el código, puede ajustar las compensaciones para nuevas regiones o rangos de fechas fácilmente.
  2. No tiene que admitir todos los rangos de fechas o regiones, puede agregarlos según sea necesario.
  3. Las regiones no tienen que corresponder directamente con los límites geopolíticos, y para evitar la duplicación de filas (por ejemplo, la mayoría de los estados en los EE. UU. Manejan el horario de verano de la misma manera), puede tener entradas amplias de RegionClass que enlazan en otra tabla con listas más tradicionales de estados, países, etc.
  4. Para situaciones como EE. UU., Donde la fecha de inicio y finalización del horario de verano ha cambiado en los últimos años, esto es bastante fácil de tratar.
  5. Como el campo StartDateTime también puede almacenar una hora, el tiempo de cambio estándar a las 2:00 a. M. Se maneja fácilmente.
  6. No en todas partes del mundo se usa un horario de verano de 1 hora. Esto maneja esos casos fácilmente.
  7. La tabla de datos es multiplataforma y podría ser un proyecto separado de código abierto que podría ser utilizado por desarrolladores que usan casi cualquier plataforma de base de datos o lenguaje de programación.
  8. Esto se puede usar para compensaciones que no tienen nada que ver con las zonas horarias. Por ejemplo, los ajustes de 1 segundo que ocurren de vez en cuando para ajustar la rotación de la Tierra, los ajustes históricos dentro y dentro del calendario gregoriano, etc.
  9. Como esto se encuentra en una tabla de base de datos, las consultas de informes estándar, etc. pueden aprovechar los datos sin un viaje a través del código de lógica de negocios.
  10. También maneja las compensaciones de zona horaria si así lo desea, e incluso puede dar cuenta de casos históricos especiales en los que una región está asignada a otra zona horaria. Todo lo que necesita es una fecha inicial que asigne un desplazamiento de zona horaria a cada región con una fecha de inicio mínima. Esto requeriría crear al menos una región para cada zona horaria, pero le permitiría hacer preguntas interesantes como: "¿Cuál es la diferencia en el horario local entre Yuma, Arizona y Seattle, Washington, el 2 de febrero de 1989 a las 5:00 am?" (Basta con restar una SUM () de la otra).

Ahora, la única desventaja de este enfoque o cualquier otro es que las conversiones de hora local para GMT no son perfectas, ya que cualquier cambio de horario de verano que tiene un desplazamiento negativo para el reloj repeticiones una hora local dada. No es una forma fácil de lidiar con eso, me temo, que es una de las razones por la que almacenar las horas locales es, en primer lugar, una mala noticia.


15