Es fácil suponer que, una vez que conoces la zona horaria de un país, la conoces para siempre. En la práctica, los gobiernos cambian su política de zona horaria con más frecuencia de lo que la mayoría de la gente cree. Un país puede decidir dejar de aplicar el horario de verano después de haberlo usado durante décadas. Otro puede desplazar una hora su desfase estándar para alinearse mejor con un socio comercial importante. Un país grande puede redibujar la frontera interna entre dos de sus zonas a medida que cambia la administración regional. Ninguna de estas categorías es hipotética. Cambios así ocurren en algún lugar del mundo con bastante regularidad, aunque un país concreto pueda pasar años o décadas entre un cambio y otro.
Este es exactamente el problema que resuelve la base de datos de zonas horarias de IANA. En lugar de almacenar un único desfase actual por país, registra cada zona con nombre como un historial de reglas a lo largo del tiempo, y añade entradas cada vez que un gobierno anuncia un cambio. El software que se nutre de una copia mantenida y actualizada con regularidad de esta base de datos incorpora los cambios sin modificar su propio código. El software que codifica los desfases por país, quizá en una tabla de consulta escrita una sola vez durante el desarrollo inicial, empezará a fallar en silencio la próxima vez que cualquiera de los países cubiertos cambie sus reglas, y el fallo no se anunciará. Simplemente empezará a devolver horas locales incorrectas para ese país hasta que alguien lo note.
Por eso también es arriesgado almacenar solo un desfase UTC, separado de una zona con nombre, para cualquier dato que vaya a usarse durante más de unos pocos meses. Un desfase capturado hoy es una instantánea de una regla que podría cambiar. Un nombre de zona como Pacific/Auckland o Asia/Kolkata lleva una referencia al conjunto de reglas mantenido, así que, mientras la base de datos subyacente esté al día, los cálculos con ese nombre siguen siendo correctos incluso después de un cambio de reglas, sin que tengas que tocar tus propios datos.
La recomendación práctica para cualquiera que trabaje con datos de zona horaria es sencilla. Almacena nombres de zona, no desfases sin más, en tu propia base de datos. Mantén actualizada con una frecuencia razonable la biblioteca o fuente de datos de zonas horarias de la que dependas, ya que una copia desactualizada se comporta exactamente como una tabla codificada en cuanto un país cubierto cambia sus reglas. Y trata una consulta de zona horaria como algo que se llama de nuevo para cálculos ligados a fechas reales y cambiantes, no como un valor que se guarda en caché indefinidamente.
Nuestra consulta de zona horaria devuelve el nombre de zona IANA y el desfase actuales para cualquier coordenada, calculados con un conjunto de reglas mantenido en lugar de una tabla estática, que es la única forma de seguir siendo correctos a medida que los países ajustan sus propias reglas con el tiempo.
Una dirección en el centro de una ciudad bien cartografiada no te dice casi nada sobre cómo gestiona tu sistema una ruta rural, una frontera en disputa o una consulta cerca de los polos. Prueba los casos difíciles a propósito.
No todos los conjuntos de datos con información de ubicación de apariencia pública pueden usarse legalmente dentro de un producto de pago. Las condiciones de la licencia, y no la disponibilidad técnica, suelen marcar el límite real.
Cuando una consulta realmente no se puede resolver de forma fiable, no devolver nada es mejor respuesta que devolver una suposición disfrazada de hecho. Este es el razonamiento detrás de esa decisión.