Resumen

  • El RFC 3339 original separó -00:00, un instante UTC conocido con desfase local desconocido, de Z y +00:00, que presentaban UTC como referencia preferida. El RFC 9557 otorgó más tarde a Z el significado de desfase desconocido y mantuvo intacto +00:00.
  • Normalizar no conserva por sí solo la prueba. Octetos originales, perfil interpretativo, procedencia del desfase, precisión escrita, estado del reloj, tabla de segundos intercalares, captura y resultado de aplicación necesitan recibos propios.

La fila quedó limpia y perdió su historia

El riesgo aparece cuando una canalización hace exactamente lo que se le pidió. Analiza una marca temporal, la convierte a UTC y guarda un formato canónico. La consulta cronológica funciona; la auditoría posterior ya no puede saber qué escribió el productor.

En 2002, la sección 4.3 de RFC 3339 dio a -00:00 un papel especial. El instante UTC era conocido, pero no se conocía la relación con la hora local. Z y +00:00 comunicaban otra procedencia: UTC era el punto de referencia preferido. Las formas podían coincidir en el instante y diferir en la información que declaraban.

La idea tenía un antecedente en el correo de Internet. RFC 2822 y su sucesor RFC 5322 usan -0000 para una hora expresada en Tiempo Universal que no aporta información sobre la zona local del sistema generador. La cronología se conserva, pero el contexto local queda explícitamente ausente.

La revisión de 2024 no fue una simple nota editorial

RFC 9557 explicó por qué la convención original no interoperaba bien. ISO 8601:2000 y sus ediciones posteriores no admitían el cero negativo, y muchas implementaciones usaban Z cuando querían decir que el desfase local era desconocido. La actualización alineó RFC 3339 con esa práctica.

Desde la actualización, Z puede expresar un instante UTC conocido sin información sobre el desfase local. +00:00 no cambió y sigue implicando que UTC es la referencia preferida. -00:00 no fue formalmente deprecado, aunque Z es la opción recomendada en su lugar.

Así, el mismo texto debe interpretarse con conocimiento del perfil aplicable. Guardar solo segundos normalizados destruye el token; guardar el token sin la versión interpretativa deja abierta otra ambigüedad. La unidad de evidencia contiene ambos.

La norma tampoco demuestra qué versión ejecutaba un producto. Hace falta registrar biblioteca, configuración, fecha de despliegue y resultado de pruebas. Una actualización documental no migra automáticamente los archivos ni el software.

El desfase no identificaba la zona

RFC 3339 define el desfase como hora local menos UTC. Permite calcular el instante, pero no da el nombre de la zona ni su política. Dos lugares pueden compartir -05:00 hoy y adoptar transiciones distintas mañana; incluso una misma jurisdicción puede cambiar sus reglas.

RFC 8536 separa esa información en TZif: transiciones, tipos de hora local, designaciones y correcciones de segundos intercalares. Una marca con desfase numérico no prueba qué archivo o versión tenía la máquina.

Para investigar una ejecución hay que enlazar el instante con la configuración de zona, la versión de datos y la regla elegida. Convertir a UTC resuelve la posición temporal, no la procedencia civil ni la intención futura.

Desfase desconocido y hora flotante respondían preguntas distintas

El cero negativo no significaba que faltara el instante. Significaba que faltaba el vínculo local. RFC 3339 rechazó la hora local sin calificador para el intercambio general porque fuera de su zona se interpretaría mal.

RFC 5545, en cambio, define una hora flotante de manera deliberada. Una cita a las 11:00 puede conservar las mismas cifras para cada asistente y ocurrir en instantes distintos. No está vinculada a una zona hasta que el contexto del receptor la aplica.

Un esquema que etiqueta ambos casos como unknown_timezone confunde dos modelos. En uno se conoce el instante y no su procedencia local. En el otro se conoce la lectura del reloj y se deja que el contexto determine el instante.

El orden de cadenas no era una propiedad universal

RFC 3339 buscó que las cadenas pudieran ordenarse como texto, pero acotó la promesa. Las zonas deben ser las mismas, su escritura debe coincidir y todas las fracciones deben tener igual cantidad de dígitos. Solo dentro de ese carril el orden lexical produce una secuencia temporal.

Mezclar desfaces, usar Z en unas filas y +00:00 en otras, o combinar una y seis cifras fraccionarias sale del contrato. La gramática también acepta t y z minúsculas, aunque otro protocolo puede exigir mayúsculas. Los errata verificados ajustan formulaciones y separan el perfil de Internet de la gramática ISO recopilada en el apéndice.

Un índice puede crear una clave canónica segura, pero debe demostrar la regla de comparación y conservar el original. Si no, una optimización de consulta se convierte en una transformación irreversible de evidencia.

Más decimales no mejoraban el reloj

La fracción de segundo es la única opción poco frecuente que RFC 3339 mantuvo. Puede servir para un orden estricto o una precisión especial, y admite uno o más dígitos. Esa longitud describe la representación, no la exactitud real.

Un reloj sin sincronizar puede imprimir nanosegundos ficticios. Otro, bien disciplinado, puede publicar segundos enteros. RFC 5905 documenta por separado la sincronización NTP, la jerarquía de fuentes, los desfases y el tratamiento del error. Ninguno de esos datos está certificado por un sufijo decimal.

La evidencia debe distinguir resolución, precisión escrita, incertidumbre, fuente, última sincronización y ruta de captura. Rellenar con ceros cambia la cadena; no añade una medición.

El segundo 60 necesitaba una tabla

RFC 3339 acepta 60 al final de un mes con un segundo intercalar positivo y contempla un máximo de 58 si se retira un segundo. Una expresión gramatical no confirma que la autoridad haya programado la corrección para esa fecha.

RFC 8536 muestra registros y correcciones intercalares dentro de datos versionados; RFC 5905 aporta otro plano de estado del reloj. Por eso, admitir una cadena terminada en el segundo 60 no equivale a validar su calendario.

Además, no todas las escalas numéricas cuentan los saltos igual. Antes de comparar, hay que registrar escala, tabla y función de conversión. De lo contrario, dos números aparentemente cercanos pueden representar convenciones distintas.

La marca no autenticaba el hecho

RFC 3339 estandarizó sintaxis, no confianza. No dice quién produjo la fecha, cuándo se adjuntó, qué objeto cubría ni si la acción ocurrió. Una firma puede no incluir el campo; una recepción puede ser posterior a la captura; un reloj mal configurado puede generar una fecha futura perfectamente válida.

El recibo completo une bytes originales, versión de perfil, campos analizados, instante derivado, token de desfase, evidencia del reloj, incertidumbre, datos de zona y salto, hash del objeto, cobertura criptográfica, transporte y resultado de la aplicación.

La misma instantánea puede necesitar dos historias: una para situarla en el tiempo y otra para explicar por qué esa situación es creíble. La primera cabe en un valor normalizado. La segunda desaparece si se borra el texto que llegó.

Fuentes