Un agente de soporte en una oficina que ve un ticket abierto a las "3:47 AM" no tiene ni idea de si es tarde para el cliente o si está en mitad de su jornada laboral. Las marcas de tiempo sin zona horaria son casi inútiles cuando los clientes de una empresa están repartidos por varios continentes, y una empresa de software con equipos de soporte en tres regiones se topaba con esto constantemente. Los agentes abrían tickets, miraban el país de facturación del cliente y luego comprobaban a mano si ese país iba por delante o por detrás, y se equivocaban con tanta frecuencia que "perdona que te moleste tan temprano" se convirtió en una broma recurrente en la oficina.
La empresa sustituyó las conjeturas por dos llamadas que se hacen cuando llega un ticket. Primero, /v1/ip lee la dirección IP del visitante y devuelve país, región, ciudad y coordenadas, junto con un campo de zona horaria directamente en la misma respuesta. Para la mayoría de los tickets, ese campo bastaba. Para el número más reducido de casos en los que importaba más la precisión, como programar una devolución de llamada, las coordenadas de esa consulta se enviaban a /v1/timezone, que devuelve el nombre de la zona horaria IANA y el desfase UTC actual de ese punto exacto, calculado opcionalmente para un momento concreto en lugar de para ahora mismo.
El nombre IANA importa más de lo que parece. Un desfase UTC sin más cambia con las normas de horario de verano, que difieren según el país y a veces según la región dentro de un país, así que guardar "UTC+2" en la ficha de un cliente se vuelve incorrecto sin avisar dos veces al año. Guardar "Europe/Warsaw" en su lugar significa que el desfase siempre se calcula correctamente para la fecha en que se programe un ticket o una devolución de llamada, porque la base de datos de zonas horarias que lo respalda sigue esos cambios de normas a medida que se producen.
El cambio visible fue una pequeña línea en la parte superior de cada ticket: la hora local del cliente en este momento, junto a su nombre. Los agentes dejaron de preguntar "¿es tarde donde estás?" y empezaron a abrir los mensajes con un "buenas tardes" acertado. El enrutamiento de tickets también mejoró, una vez que la cola pudo ordenar por qué clientes estaban en ese momento dentro del horario laboral de su propia región, en lugar de por qué equipo de soporte tenía personal en ese momento.
Nada de esto necesitó una base de datos de correspondencias entre países y zonas horarias mantenida a mano, que era el apaño que la empresa había montado antes y que fallaba cada vez que la IP de un cliente correspondía a un país grande con varias zonas. Leer la zona horaria directamente a partir de las coordenadas eliminó toda esa categoría de errores.
El volumen era bajo, una consulta por ticket nuevo, muy por debajo de las 2.500 solicitudes gratuitas al día incluidas con la clave de la empresa. La herramienta de soporte por sí sola nunca estuvo cerca de necesitar crédito prepago, aunque la misma clave cubría otras partes del producto que sí lo necesitaban.
La gestión de zonas horarias es uno de esos detalles que los clientes solo notan cuando está mal. Hacerlo bien, sin llamar la atención, en segundo plano en cada ticket, es un arreglo pequeño con un efecto desproporcionado en la imagen que da un equipo de soporte. La documentación de ambos endpoints está en /docs/ipv4-lookup/ y /docs/timezone-lookup/.