Si te sitúas a poca distancia de la línea internacional de cambio de fecha, es perfectamente posible que tu vecino al otro lado de esa línea esté viviendo una fecha de calendario distinta a la tuya, aunque los dos vean aproximadamente la misma hora local en el reloj y estén físicamente cerca. Es uno de los hechos más desconcertantes sobre cómo se organiza la medición del tiempo en el mundo, y tiene consecuencias reales y prácticas para cualquier lógica dependiente de la fecha que funcione cerca de ella.
La línea de cambio de fecha existe porque las zonas horarias se acumulan alrededor del planeta hasta encontrarse en algún punto, y por una convención de larga data ese punto de encuentro sigue aproximadamente el meridiano 180 en el Pacífico, trazado a propósito por mar abierto y rodeando las tierras habitadas en la medida de lo posible, precisamente para reducir al mínimo los lugares situados justo sobre el salto. Cruzarla en un sentido retrasa tu fecha de calendario un día. Cruzarla en el otro la adelanta un día. Esto es independiente de la diferencia normal de desfase horario que esperarías al cruzar cualquier otro límite de zona, y se suma a ella.
Para la mayoría de las aplicaciones esto nunca llega a plantearse, ya que la línea pasa sobre todo por el océano y el número de personas y empresas que operan justo en su borde es pequeño. Se convierte en una preocupación real específicamente para las aplicaciones que operan en los países y territorios insulares del Pacífico cercanos a la línea, donde un sistema de programación, una plataforma de reservas o cualquier cosa que calcule "qué día es ahora mismo en este lugar" necesita acertar con el trazado exacto de la línea, no solo con el desfase general de la zona horaria, o calculará una fecha de calendario de apariencia plausible pero errónea para los lugares muy cercanos a ella.
Precisamente por eso, apoyarse en una consulta de zona horaria adecuada, vinculada a la zona IANA real de un lugar concreto, importa aquí más que casi en ningún otro sitio. Un cálculo ingenuo basado solo en la longitud y en una fórmula de desfase simple fallará con la línea de cambio de fecha, ya que su trazado real se aparta a propósito de una línea recta de longitud en varios puntos, precisamente para mantener a algunos países y territorios insulares en una misma fecha coherente en lugar de dividirlos de forma incómoda a ambos lados de la línea.
Si tu aplicación opera en cualquier lugar cerca del Pacífico y calcula fechas, no solo horas, según la ubicación, usa una consulta de zona horaria adecuada vinculada a la zona real de esa coordenada en lugar de deducir la fecha directamente de la longitud, y haz pruebas explícitas con lugares que se sabe que están cerca de la línea de cambio de fecha en lugar de suponer que tu manejo general de zonas horarias cubre automáticamente y de forma correcta este caso límite concreto.
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.