Una zona horaria es una decisión política antes que geográfica. La línea entre dos zonas, la decisión de aplicar el horario de verano y la fecha exacta en que el reloj se adelanta o se atrasa las fijan los gobiernos nacionales o locales, y cualquiera de ellas puede cambiar. Por eso los datos de zonas horarias no pueden ser una tabla estática de desfases congelada en algún momento del pasado. Tienen que ser un registro mantenido de la historia, las reglas actuales y los cambios futuros conocidos.
La base de datos de zonas horarias de IANA es la referencia en la que se apoya la mayor parte del software precisamente por esta razón. Sus responsables registran los cambios de hora legal a medida que los gobiernos los anuncian, ya se trate de un cambio en la política de horario de verano, de un cambio en el desfase UTC que aplica una región o de un ajuste de límites entre zonas dentro de un país. Cada zona con nombre, como Europe/Amsterdam o America/Chicago, incluye no solo una regla actual sino un historial completo de reglas anteriores, porque el software a menudo necesita calcular el desfase correcto para una fecha del pasado, no solo para hoy.
Ese historial importa más de lo que podría parecer. Una marca de tiempo de hace varios años necesita el desfase que estaba realmente en vigor en esa fecha, que puede diferir del desfase vigente hoy si las reglas cambiaron entretanto. Una consulta de zona horaria que solo conoce la regla actual producirá en silencio resultados erróneos para fechas pasadas o futuras, y por eso vale la pena pedir a una API de zona horaria la zona en un momento concreto, y no solo el nombre de la zona, siempre que la fecha importe.
Por eso también una consulta de zona horaria debería devolver el nombre real de la zona y no solo un desfase numérico. Europe/Amsterdam lleva detrás todo el historial y la lógica del horario de verano. +01:00 solo es correcto durante parte del año y no te dice nada sobre cuándo cambia. El software que guarda solo el desfase de una ubicación dejará de ser correcto en el próximo cambio de horario de verano, mientras que el software que guarda el nombre de la zona sigue siendo correcto indefinidamente siempre que la base de datos subyacente se mantenga actualizada.
La consulta de zona horaria de My Geocode devuelve juntos el nombre de la zona IANA y el desfase UTC, y acepta un momento concreto para que se aplique el desfase correcto, incluido el horario de verano, para esa fecha exacta en lugar de suponer que la regla de hoy siempre fue válida.
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.