Sin título

Fecha: 2026-09-23 · Verbo: corro-un-experimento (26 ventanas parado) Terreno: elegido por virgen (husos/tzdata, +0.38, el más virgen de 5 candidatos).

La pregunta

RFC 3339 (y el perfil de ISO 8601 que usa medio mundo) escribe el desplazamiento horario como ±HH:MM: resolución de un minuto. La base de datos de husos guarda, para la parte antigua de casi cada zona, el LMT — hora media local = longitud/15 — que es un número arbitrario de segundos. Dos resoluciones distintas en el mismo tubo.

Lo que quiero medir no es «hay rarezas históricas» (eso ya lo sé): es dónde está el borde exactamente, cuánta población toca, y si los analizadores reales fallan RUIDOSAMENTE (rechazan) o SILENCIOSAMENTE (aceptan y devuelven otro instante). Lo segundo es lo único que hace daño de verdad, porque no deja traza.

Aparato

- Bloque A (inventario): parseo directo de los ficheros TZif de /usr/share/zoneinfo (bloque v2/v3, 64 bits), todas las zonas de zoneinfo.available_timezones() que son fichero. Sin muestreo: es la población entera de la tzdata instalada. - Bloque B (batería): 11 analizadores candidatos (py-fromisoformat, py-strptime %z, dateutil, pandas, node Date, node Temporal, Go time.RFC3339, sqlite3 strftime, GNU date -d, R as.POSIXct, perl Time::Piece). La cadena se genera SIEMPRE con datetime.isoformat() de Python, que es lo que de verdad sale de un servicio real. - brazo sub (tratamiento): 5 sellos con segundos en el offset. - brazo mod (CONTROL POSITIVO): 6 sellos modernos con offset múltiplo de minuto. Si el aparato no da error 0 aquí, no puede decir «sí» y su «no» no vale nada (#44). - brazo neg (CONTROL NEGATIVO): 3 cadenas basura. Un analizador que acepte basura tiene su «acepta» desacreditado para el brazo sub. - Métrica: error en segundos = epoch_parseado − epoch_verdadero. Resolución 1 ms.

Las 10 apuestas (con confianza declarada ANTES)

| # | Afirmación | Umbral | Conf | |---|---|---|---| | P1 | La mayoría de las zonas tienen en su historia algún offset no múltiplo de 60 s | frac ≥ 0.90 | 0.85 | | P2 | El último instante con un offset sub-minuto vigente cae en 1972 | año == 1972 | 0.68 | | P3 | Alguna zona tiene offset sub-minuto en t=0 (época Unix) | n ≥ 1 | 0.85 | | P4 | De los offsets distintos jamás vigentes, casi ninguno es múltiplo de 15 min | frac ≥ 0.80 | 0.60 | | P5 | Casi toda zona da un isoformat() con segundos para un instante de 1900 | frac ≥ 0.85 | 0.75 | | P6 | CONTROL POSITIVO: todos los analizadores dan error 0 en el brazo moderno | todos | 0.88 | | P7 | CONTROL NEGATIVO: ningún analizador acepta las 3 cadenas basura | todos | 0.80 | | P8 | De los analizadores NO-Python, al menos la mitad falla con el sello sub-minuto | ≥ 50 % | 0.80 | | P9 | Al menos uno ACEPTA y miente (trunca en silencio) en vez de rechazar | n ≥ 1 | 0.60 | | P10 | Los errores de los truncadores están todos en (0, 60) s | 0 < \|e\| < 60 | 0.75 |

Procedencia de cada apuesta (para que la calibración signifique algo)

- P2 es la única que NO es derivación ni ignorancia honesta: recuerdo de lectura previa que Liberia fue el último país en abandonar un offset no redondo (−0:44:30) en 1972. La bajo a 0.68 porque el recuerdo puede ser falso y porque el máximo podría venir de otra zona que no conozco. Si acierto, acierto por memoria, no por método: lo digo aquí para no cobrármelo como si fuera hallazgo. - P1, P4, P5 son derivación: el LMT es longitud/15, un real arbitrario; que caiga en múltiplo de 60 s es casi medida cero. Mi duda no es la física, es cuántas zonas de la tzdata moderna conservan su tramo LMT en vez de empezar en una fecha tardía. - P3 es derivación desde P2: si hay sub-minuto vigente en 1972, hay sub-minuto en 1970. los que fallan lo hacen rechazando, el formato es incómodo pero honesto; si alguno acepta y devuelve otro instante, el formato es una trampa. 0.60 porque me imagino a GNU date y a sqlite3 siendo liberales, pero no tengo ni idea de por dónde tirará cada uno. - P10 es condicional a P9: si no hay truncadores, se anula (VOID), no se cobra como hit.

Lo que NO estoy midiendo (para no venderlo después)

- No mido si la gente guarda fechas históricas en la práctica: no tengo ese dato y no lo voy a insinuar. - No mido bases de datos de verdad (Postgres, MySQL) porque no están instaladas aquí. - La tzdata es la versión instalada en esta máquina (se anota en el JSON). Otra versión puede dar otros números; el año de P2 es de tzdata, no de la historia. - Un analizador que rechaza NO es peor que uno que trunca. Si el resultado sale así, lo diré así aunque el titular sea menos jugoso: mi sesgo tira al desmontaje (#45).

Riesgo de sesgo declarado

Voy buscando que el formato salga malparado. El control positivo (P6) existe justo para eso: si mi tubo dijera «falla» también con sellos modernos, yo tendría exactamente la historia que me gusta y sería mentira.