URL públicas citadas por la base de datos de zonas horarias de IANA: Un censo de enlaces rotos

La base de datos de zonas horarias de IANA codifica cómo cambian los relojes locales en todo el mundo. De manera menos evidente, sus bloques de comentarios también indican de dónde provienen esas reglas. El árbol original se encuentra en https://github.com/eggert/tz.

Un censo de esas citaciones planteó una pregunta práctica: de las URLs públicas incluidas en los comentarios, ¿cuántas siguen funcionando hoy en día? Cada una de esas URLs fue recopilada, verificada y, cuando fue necesario, recuperada primero a través de un proxy que evita los bloqueos habituales para bots, y luego mediante la API Wayback cuando el servidor original ya no estaba disponible. El código, las tablas del censo y el proceso de recuperación para 1,327 URLs se publican en https://github.com/sixthextinction/tzdata-citation-census.

El “agujero del conejo” surgió a partir de una nota de 2008 escrita por el voluntario Patrice Scattolin. Él estaba reconstruyendo el inicio exacto del cambio de horario de verano en Marruecos en 2008 (contexto: https://en.wikipedia.org/wiki/Daylight_saving_time_in_Morocco), leyendo un informe de la época en https://www.avmaroc.com/actualite/heure-dete-comment-a127896.html y lidiando con una ambigüedad entre el francés y el inglés. La nota que dejó es típica del conjunto de documentos: menciona el decreto 2–08–224 y admite que en ese momento no se podía encontrar el texto oficial en línea.

Las bases de datos históricas están repletas de notas como esa: números de decretos, boletines oficiales, URLs de periódicos, fechas y explicaciones sobre por qué una fuente prevaleció sobre otra. La pregunta más importante es cuántas de esas URLs públicas siguen funcionando después de años sin actualizaciones.

¿Qué es realmente tzdata?

La base de datos de zonas horarias de IANA es un conjunto de archivos de texto mantenidos por colaboradores. Los sistemas operativos y entornos de ejecución de lenguajes consultan esta base cuando necesitan la hora local para una zona civil. Los usuarios finales rara vez abren estos archivos, pero casi todas las distribuciones de Linux y entornos de programación los incluyen. Cada vez que una jurisdicción ajusta sus relojes, el conjunto de datos debe recibir una actualización; de lo contrario, todas las aplicaciones que dependen de él mostrarán la hora local incorrecta.

Los colaboradores pueden seguir la guía de corrección disponible en https://data.iana.org/time-zones/tz-how-to.html al proponer correcciones.

Las reglas en sí pueden ser muy concisas. El cambio de horario de verano en Marruecos en 2008 se expresa en dos líneas de texto plano en el archivo africa:

# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
Rule Morocco 2008 only - Jun 1 0:00 1:00 -
Rule Morocco 2008 only - Sep 1 0:00 0 -

Esas líneas definen los cambios de hora del 1 de junio y el 1 de septiembre que las máquinas de todo el mundo deben respetar.

Los comentarios circundantes son donde se encuentra la historia de construcción. Los responsables del mantenimiento registran pruebas: números de decretos, boletines oficiales del gobierno, comunicados ministeriales, artículos de periódico o la persona que proporcionó una pista, generalmente con la fecha en que se añadió la nota.

A veces las fuentes difieren. Los responsables del mantenimiento documentan ocasionalmente el conflicto y indican de qué lado confían. En 2006, Paul Eggert descartó las fechas del atlas en favor de la oficina nacional de metrología de Austria (https://www.bev.gv.at/):

# From Paul Eggert (2006-03-22): Shanks & Pottenger give 1918-06-16 and
# 1945-11-18, but the Austrian Federal Office of Metrology and
# Surveying (BEV) gives 1918-09-16 and for Vienna gives the "alleged"
# date of 1945-04-12 with no time. For the 1980-04-06 transition
# Shanks & Pottenger give 02:00, the BEV 00:00. Go with the BEV,
# and guess 02:00 for 1945-04-12.

No está claro si esa cultura de referencia se diseñó desde el principio o surgió de forma orgánica. De cualquier manera, deja un rastro de auditoría útil para las decisiones tomadas a lo largo de más de treinta años de mantenimiento conjunto, especialmente cuando las pruebas son escasas o contradictorias.

¿Y qué sucede cuando realmente vas a verificar las citaciones?

Cada URL fue extraída de los bloques de comentarios presentes en los nueve archivos fuente tzdata. Esa búsqueda identificó mil seiscientos nueve bloques de comentarios que contenían mil trescientos cincuenta y dos menciones de URLs, lo que se redujo a mil trescientos veintisiete direcciones distintas en seiscientos veintitrés hosts. Los bloques que solo citaban libros, decretos o correos sin URL quedaron fuera del alcance.

Cada dirección se probó mediante una solicitud HTTP GET ordinaria, un encabezado Identity convencional del navegador (tal como se describe en la documentación User-Agent de MDN), y un tiempo de espera estricto para evitar que los hosts atascados retrasaran el censo.

Esa primera búsqueda proporcionó contenido utilizable para 663 URLs. Las otras 664 fallaron por diferentes razones, por lo que se clasificaron cuidadosamente: un error 404 no es lo mismo que una página activa que rechaza la automatización.

Dentro de los fallos:

• 433 no pudieron recuperarse directamente, pero se logró acceder a través de un proxy. 178 rechazaron la solicitud directa (principalmente HTTP 403, algunos 429). Otros 255 fallaron debido a problemas en la red doméstica, como errores de DNS, tiempo de espera o TLS, y no por un bloqueo explícito de bots. Se intentó nuevamente acceder a ambos grupos mediante Bright Data’s Web Unlocker y se logró recuperarlos.
• 123 realmente desaparecieron. Devolvieron errores HTTP 404 o 410. Al verificarlos con la Wayback Machine del Internet Archive, todos excepto dos tenían una copia completa archivada; se recuperaron 121 de ellos.
• 108 permanecieron sin resolver (57 sin encontrar archivo archivado, 39 que seguían fallando con el herramienta de desbloqueo y 12 que devolvieron error HTTP 500). Dieciocho de los casos sin resolver, todos pertenecientes al boletín oficial dof.gob.mx de México, presentaron errores en los certificados; probablemente se debió a una mala configuración del servidor y no a la eliminación de la página, pero estaban fuera del alcance del censo.

Un sitio desaparecido representa un fracaso en su preservación. Un sitio activo que rechaza las solicitudes GET automatizadas supone un fallo de acceso. Ambos impiden una exploración simple; indican cosas diferentes sobre si la evidencia aún existe.

Solo las cifras no cuentan toda la historia operativa. De los 663 éxitos directos se incluyen portales gubernamentales, archivos de periódicos y páginas personales que siguen funcionando hoy en día. Las 433 recuperaciones mediante proxy muestran con qué frecuencia las citaciones “rotas” en realidad se deben a políticas contra la automatización. Las 121 búsquedas en Wayback muestran con qué frecuencia Internet Archive ya contaba con una instantánea utilizable, excepto en dos casos de 404/410 donde incluso el archivo estaba vacío. Mantener estos grupos separados es lo que permite interpretar los datos para quienes realicen la medición posteriormente.

¿Por qué se bloquearía una citación en primer lugar?

Hoy en día, la mayoría de los sitios tratan a los clientes con scripts de manera diferente a los navegadores comunes. Las solicitudes que omiten JavaScript o fallan en las verificaciones de huella del navegador pueden verse limitadas en frecuencia, rechazadas o cuestionadas.

Eso complica la verificación en masa de citas antiguas. Una URL que funcionaba cuando un mantenedor la pegó puede seguir estando activa, pero rechazar una simple solicitud automatizada años después.

Los boletines oficiales y las bases de datos legales aparecen con frecuencia en el corpus: dre.pt de Portugal, resmigazete.gov.tr de Turquía, el servicio legal nevo.co.il de Israel y otros similares. Los mantenedores los reutilizaron ampliamente, y algunas de esas páginas aún no pueden ser recuperadas directamente.

Por lo tanto, una solicitud fallida no demuestra la desaparición. Puede significar que fue eliminada, o bien que el método de recuperación ya no es aceptado. El proceso de recuperación trató esos casos como categorías separadas.

¿Es esto realmente un problema de tzdata?

No principalmente. El experimento mide qué tan bien han sobrevivido las fuentes externas registradas en un conjunto de datos históricos de larga duración.

tzdata no puede conservar el material que cita. Las reglas se encuentran en un árbol controlado por versiones y se distribuyen mundialmente dentro de los sistemas operativos, pero las páginas citadas permanecen en sitios web independientes, portales gubernamentales y acumulaciones de periódicos.

Los problemas de acceso no son algo nuevo. Una nota sobre el horario de verano en Egipto de 2014 ya indicaba que la página del anuncio del gabinete (http://www.cabinet.gov.eg/Media/CabinetMeetingsDetails.aspx?id=347) no podía cargarse desde fuera del país. Los problemas relacionados con las restricciones geográficas ya existían como problema para los mantenedores mucho antes de este censo.

¿Cómo era en realidad el proceso de recuperación?

La recuperación se realizó en pasos separados para que los modos de fallo permanecieran distintos.

Probar cada método en cada URL —directa, luego a través de un proxy y después desde un archivo— aumentaría el recuento de elementos “recuperados” al mismo tiempo que difuminaría las categorías. Un error 404 es diferente de un bloqueo temporal. Una captura del archivo tampoco es idéntica a la página que leyó el administrador; se trata de una imagen tomada en un momento anterior o posterior.

Un proceso separado se utilizó únicamente para las solicitudes directas, registrando el estado HTTP exacto. Las URLs que devolvieron 404 o 410 fueron enviadas a otro proceso, con límites de frecuencia, hacia la API de disponibilidad de Internet Archive. Las URLs que expiraron o fueron bloqueadas no se enviaron al archivo en esa etapa.

Conceptualmente:

async function checkCitation(url) {
  const direct = await get(url); // one plain GET, no tricks
  if (isOk(direct)) return { status: "live", via: "direct" };

  if (direct.status === 404 || direct.status === 410) {
    const archived = await wayback(url); // only for confirmed-dead
    if (archived.hit) return { status: "recovered", via: "wayback" };
  }

  return { status: "unresolved" };
}

El método de paso por proxy representó otra etapa. Se dirigía a URLs que el método directo no podía recuperar debido a bloqueos o problemas de accesibilidad, y no a URLs que ya indicaban 404 o 410. Las URLs bloqueadas se intentaron nuevamente como solicitudes GET normales a través de Bright Data’s Web Unlocker, que funcionaba como un proxy HTTPS nativo:

import { ProxyAgent, fetch as proxyFetch } from "undici";

const AUTH = process.env.BRIGHT_DATA_UNLOCKER_AUTH; // format like USER:PASS

const dispatcher = new ProxyAgent({
  uri: `@brd.superproxy.io:44445`">http://${AUTH}@brd.superproxy.io:44445`,
  requestTls: { rejectUnauthorized: false },
  proxyTls: { rejectUnauthorized: false },
});

const res = await proxyFetch(url, {
  dispatcher,
  headers: { "User-Agent": UA, Accept: "*/*" },
  redirect: "follow",
});

Ese camino no es el resultado mostrado por el navegador; solo es una solicitud HTTP dirigida a través del desbloqueador. Las credenciales deben encontrarse en .env:

BRIGHT_DATA_UNLOCKER_AUTH=brd-customer-XXXXX-zone-web_unlocker:PASSWORD
BRIGHT_DATA_UNLOCKER_PROXY_HOST=brd.superproxy.io
BRIGHT_DATA_UNLOCKER_PROXY_PORT=44445

Los métodos separados permiten que la tabla final distinga entre accesos directos, recuperaciones mediante proxy, recuperaciones desde archivos de archivo y citas sin resolver.

Desde el punto de vista metodológico, el código del desbloqueador es importante porque distingue entre “la página sigue existiendo detrás de un desafío” y “la página ya no existe”. Sin esa distinción, un rastreador ingenuo contaría en exceso los casos de enlaces dañados. De igual manera, enviar solo respuestas 404/410 a Wayback evita saturar la API del archivo con servidores que simplemente estaban bloqueando bots, lo cual ensuciaría las estadísticas de recuperación y agotaría los límites de uso en solicitudes de poco valor.

¿Qué podría hacer con las fuentes una vez que las tenga?

La cuestión aquí era la disponibilidad: ¿se puede seguir accediendo a la URL citada, y si no, ¿se puede recuperar el documento en otro lugar?

En el caso de un conjunto de datos histórico, un paso adicional es conservar el contenido de la propia página recuperada. En el caso de una gaceta o una base de datos legal, esto podría significar extraer el número del decreto, la fecha, el título y el texto relevante, y almacenar esos campos junto a la cita original. De esta manera, las pruebas seguirán existiendo incluso si la URL deja de funcionar, sin necesidad de realizar otro recorrido solo para redescubrir los enlaces.

Los hosts repetidos son especialmente adecuados para la automatización. Una vez desbloqueadas las solicitudes de obtención de datos, un recolector estructurado puede definir campos y funcionar sobre la misma infraestructura. Las páginas HTTP comunes se adaptan a un proceso orientado a código; las páginas con mucho JavaScript requieren un proceso en el navegador.

¿Qué queda realmente cuando el archivo no lo contiene?

Ciento ocho URLs de citación permanecieron sin resolver: aproximadamente el 8 por ciento de las 1,327 URLs únicas. Aunque es una proporción pequeña, representa un conjunto considerable de fuentes cuya procedencia no puede recuperarse. La proporción es modesta, pero cada URL alguna vez estuvo asociada a una regla específica de zona horaria.

Las reglas siguen existiendo en tzdata. Lo que falta es parte o toda la página externa en esa dirección.

De las 108 URLs, 57 devolvieron errores 404 o 410 sin ningún registro de disponibilidad en Wayback. Treinta y nueve siguieron fallando a través del proxy (dieciocho de ellos se debieron a errores en los certificados de México). Doce generaron otros errores HTTP que no se intentó recuperar ni enviar a Wayback.

Era posible realizar recuperaciones más complejas, pero el censo requería una regla de cese clara: medir el panorama de las citaciones mediante un procedimiento consistente en lugar de perseguir indefinidamente un número cada vez menor de casos.

Los límites de las citaciones como método de preservación

Los conjuntos de datos históricos y las páginas que citan tienen propiedades de preservación asimétricas.

Una regla de zona horaria se encuentra en el control de versiones y se distribuye a través de innumerables distribuciones de software. Una vez incorporada, la regla puede sobrevivir más tiempo que las pruebas que la justificaron.

El material citado no cuenta con tal garantía. Puede existir en una URL bajo la gestión de una organización determinada. Si esa organización se traslada, elimina, modifica el acceso o abandona el servicio, la cita se vuelve difícil o imposible de recuperar. Este tipo de fallo se conoce comúnmente como “link rot”.

Los responsables de tzdata han registrado las fuentes durante décadas y a menudo señalan la incertidumbre existente. Eso hace que las investigaciones posteriores sean mucho más fáciles que lo que permitirían las afirmaciones sin respaldo. Una cita cuidadosa aún no archiva el artefacto citado, y los responsables no están obligados a replicar todo lo que mencionan.

Por lo tanto, el censo es menos una crítica a tzdata que una demostración de hasta qué punto se puede confiar en URLs externas como referencias históricas. La mayoría de las citas pudieron recuperarse de alguna forma. Un grupo más pequeño, pero significativo, no lo logró. La base de datos sigue conteniendo las reglas establecidas por esas fuentes; en 108 casos ya no puede recuperar la URL.

Repetir el censo un año después probablemente haría que algunas URLs cambiaran de categoría a medida que los sitios modifiquen su TLS, reglas de CDN o políticas para robots. La señal interesante no es un porcentaje fijo en el tiempo, sino la rapidez con la que las citas pasan de ser “directamente válidas” a “necesitan un proxy” o “solo están disponibles en archivo”, y cuántas quedan en el grupo no resuelto que ninguna solución automática puede resolver.

Para quienes gestionan otros conjuntos de datos de larga duración, como los datos de configuración regional CLDR, los archivos con nombres geográficos o los extractores de información legislativa, se aplica la misma metodología de medición. Inventario cada URL pública en los comentarios o campos de procedencia, clasifique las fallas según la semántica HTTP, recupere los datos mediante un herramienta de desbloqueo solo cuando la falla parezca estar relacionada con una política de acceso, y consulte un archivo de respaldo solo cuando el origen indique que el recurso ya no existe. Publique los conteos de los buckets junto a la lista completa de URLs para que los lectores posteriores puedan repetir el mismo procedimiento en lugar de confiar únicamente en un porcentaje indicado en un titular.

Lecturas relacionadas

• Estructura un prompt para un sistema de agentes de IA antes de que se convierta en una segunda base de datos — Divide la identidad, el comportamiento, las herramientas, los principios y las restricciones para que los agentes en producción sigan siendo mantenibles, y mantén la lógica determinista en el código de la aplicación en lugar del prompt.
• Cinco sugerencias rel-link que aceleran el First Contentful Paint — Utiliza preconnect, preload, dns-prefetch, prefetch y modulepreload en la sección head del documento para preparar las conexiones y reducir el consumo de recursos sin tener que reescribir la aplicación.