La mayoría de los desarrolladores escriben su primer código de manejo de zonas horarias dando por hecho que todos los desfases son un número entero de horas respecto a UTC. Esa suposición se cumple en la mayoría de las zonas, y luego falla la primera vez que llega una solicitud desde un lugar que no la sigue. Varias partes del mundo usan desfases de media hora, y al menos una región usa un desfase de 45 minutos, y ninguno de estos casos es un caso límite en el sentido de ser raro o inválido. Es simplemente la forma en que esos lugares han decidido ajustar sus relojes en relación con el sol y con sus vecinos.
Un desfase de media hora suele reflejar que la longitud de un país se sitúa entre dos zonas horarias estándar, con la decisión de quedarse en el punto medio en lugar de redondear hacia un lado. Un desfase de 45 minutos es aún más raro y suele reflejar una posición intermedia similar combinada con la decisión deliberada de mantenerse distinto de un desfase estándar vecino. Ninguno de los dos es un error en los datos. Ambos son zonas horarias legales legítimas registradas igual que cualquier zona de horas completas en la base de datos de la IANA.
Donde esto rompe de verdad el software es en los cálculos de fecha y hora que dan por hechas ciertas suposiciones. El código que redondea los desfases a la hora más cercana, que almacena un desfase como un número entero de horas o que construye una lista desplegable de zonas horarias usando solo incrementos de hora completa y media hora manejará mal estas zonas sin avisar. Además, el fallo suele ser silencioso. Las horas se desviarán quince o treinta minutos en lugar de lanzar un error evidente, lo que hace que el error pase fácilmente desapercibido en las pruebas y solo aparezca cuando un usuario real de la región afectada informa de que algo está mal.
La solución es sencilla si lo tienes en cuenta desde el principio: trabaja siempre con el desfase UTC real que se devuelve para una zona, expresado con precisión de minutos, en lugar de suponer o redondear a horas. Siempre que puedas, almacena y compara nombres de zona en lugar de desfases, ya que el nombre incluye el desfase exacto actual e histórico sin que tengas que programar nada a mano.
Una consulta de zona horaria que devuelve el desfase exacto junto con el nombre de zona de la IANA elimina aquí las conjeturas. Consulta las coordenadas o la zona directamente en lugar de deducir el desfase de una ubicación solo a partir de su país o región, ya que los desfases pueden variar dentro de un mismo país y rara vez se ajustan limpiamente a la hora en todas partes.
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.