El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
Por qué los errores de zona horaria suelen ser un problema de pruebas y no de datos
Un error de zona horaria casi nunca aparece un martes cualquiera. Aparece justo la semana en que se produce un cambio de horario de verano, o en una región cuyo gobierno acaba de cambiar sus reglas de desfase con poca antelación, o en el límite exacto entre dos zonas, donde un caso límite en la asignación de coordenadas a zonas elige el lado equivocado. El resto del año, el código que gestiona mal las zonas horarias funciona sin ningún problema visible, y eso es exactamente lo que hace que estos errores sean tan persistentes: el modo de fallo es raro por diseño, así que rara vez se detecta hasta que ocurre de verdad en producción.
Creemos que la mayoría de estos errores se achacan a los datos cuando en realidad son una carencia en las pruebas. La base de datos de zonas horarias de la IANA, que sustenta la mayor parte de la gestión seria de zonas horarias, incluida la nuestra, registra estos cambios y modificaciones de reglas a medida que se producen. Que los datos estén disponibles no es lo mismo que una aplicación ejecute correctamente las rutas de código que solo se activan durante una semana de cambio o que solo se aplican al puñado de regiones con reglas inusuales. Si un conjunto de pruebas nunca simula un límite de horario de verano, o nunca ejecuta una consulta sobre una región con un desfase no estándar de media hora o de 45 minutos, que los datos subyacentes sean correctos no salvará a una aplicación de un error que solo su propia ruta de código sin probar puede evitar.
Este es un caso en el que la solución es aburrida y concreta, no emocionante: prueba explícitamente con las fechas del calendario en que se producen los cambios, no solo con una fecha arbitraria elegida por comodidad. Prueba deliberadamente con un puñado de regiones límite con desfases inusuales, no solo con las zonas horarias comunes y de números redondos en las que casualmente se desarrolla la mayor parte del software. Nada de esto requiere datos nuevos. Requiere decidir que la semana rara merece probarse con tanto cuidado como la habitual, ya que la semana rara es exactamente cuando el error aparecerá para un usuario real.
Hay una trampa relacionada que vale la pena nombrar: guardar en caché el desfase horario de una ubicación una sola vez y reutilizar ese valor indefinidamente. Un desfase que era correcto en julio puede ser erróneo en diciembre cuando el horario de verano lo cambia, y una caché que no lo tenga en cuenta servirá con total seguridad una respuesta obsoleta sin ninguna indicación de que algo haya ido mal. Esto tampoco es un problema de calidad de los datos. Es una decisión de arquitectura que supuso que un dato se mantendría constante cuando la naturaleza misma de esos datos es que periódicamente no lo hace.
Describimos nuestro endpoint de zona horaria como una de las partes del producto que funciona plenamente, porque los datos de referencia subyacentes se mantienen activamente y la lógica de consulta está diseñada para tener en cuenta estos cambios directamente en lugar de suponer un desfase estático. La idea de fondo va más allá de nuestro propio producto: que un error de zona horaria llegue a un cliente rara vez demuestra que los datos de origen fueran erróneos. Mucho más a menudo demuestra que nadie escribió una prueba para esa semana del año, o esa región, en la que las reglas realmente cambian.