Timestamps confiables: por qué la fecha la pone el sistema, no el usuario

Toda trazabilidad es, en el fondo, una línea de tiempo. La secuencia de eventos —recepción, propagación, vegetativo, floración, cosecha, distribución— solo tiene sentido si las fechas son confiables. Y una fecha es confiable cuando no la puede elegir libremente quien tiene interés en el resultado. Este es uno de esos detalles técnicos que casi nadie nota hasta el día en que lo necesita, y ese día resulta ser decisivo.

El campo de fecha editable es el problema

Muchos sistemas de registro presentan un campo de fecha que el usuario llena. Es cómodo y parece inofensivo. Pero tiene una consecuencia profunda: si quien crea el registro puede escribir cualquier fecha, el registro deja de probar cuándo ocurrió el hecho y solo prueba qué fecha se quiso afirmar. Esas dos cosas son completamente distintas frente a un tercero. Una bitácora con fechas escritas a mano documenta intenciones; no documenta cronología.

El riesgo no requiere mala fe. Basta con cargar todo "al final de la semana" poniendo fechas aproximadas de memoria para que la línea de tiempo se vuelva una estimación. Y una estimación no es lo que se necesita el día que alguien pregunta exactamente cuándo pasó algo.

La "C" de ALCOA: contemporáneo

Este principio tiene nombre en la integridad de datos regulada. El estándar ALCOA+ que aplican la FDA y la EMA exige, entre otras cosas, que los registros sean "contemporáneos": anotados en el momento en que la actividad ocurre, no después. La razón es exactamente la que se discute aquí. Un dato registrado después, con fecha puesta de memoria, no prueba cuándo pasó; prueba cuándo alguien decidió decir que pasó. Por eso las buenas prácticas de documentación prohíben el registro retrospectivo no justificado y exigen marcas de tiempo que el operador no controle. Que la fecha la ponga el sistema y no el usuario no es una preferencia de diseño: es el cumplimiento técnico del principio "contemporáneo".

Timestamp del lado del servidor

La alternativa correcta es que el momento de creación lo ponga la base de datos en el instante en que el registro se inserta, no el navegador del usuario ni un campo editable. El operador registra el hecho; el sistema sella cuándo lo registró. Ese sello no se pide, no se elige y no se puede ajustar después.

Quien registra puede equivocarse en un dato; no debería poder elegir cuándo dice que ese dato ocurrió.

Combinado con la inmutabilidad de los registros y con la cadena de hash, ese timestamp se vuelve parte de la prueba y no un simple adorno. No se puede retrodatar un registro sin alterar su contenido, y no se puede alterar su contenido sin romper la cadena de los registros que vinieron después. Las tres propiedades se refuerzan entre sí, igual que la pista de auditoría exigida por la 21 CFR Part 11 estadounidense para registros electrónicos.

La diferencia entre captura y momento del hecho

Conviene una precisión honesta: el timestamp del servidor prueba cuándo se registró el evento, que no es necesariamente el segundo exacto en que ocurrió físicamente. Si una poda se hizo a las nueve y se registró a las once, el sello dice "once". Eso no es un defecto; es una propiedad bien entendida y reconocida también en los marcos regulados, donde "contemporáneo" significa tan cerca del hecho como sea razonablemente posible, no instantáneo. La buena práctica operativa —registrar lo más cerca posible del hecho— cierra esa pequeña brecha, y la cierra de forma creíble justamente porque la fecha no se podía manipular.

Qué ataca esto en concreto

El timestamp del sistema neutraliza un escenario muy específico y muy difícil de descartar de otra manera: la sospecha de que el expediente se ordenó después, eligiendo fechas que hicieran calzar la historia. Sin sello confiable, esa sospecha no se puede responder más que con la palabra de la asociación. Con sello del servidor encadenado, la respuesta es estructural.

• La fecha la pone la base de datos al insertar, no el usuario.
• El registro es inmutable: no se puede editar para cambiar esa fecha.
• La cadena de hash detecta cualquier intento de retrodatar por fuera del sistema.

Un detalle pequeño con consecuencias grandes

Orden temporal y reloj: dos cosas distintas

Conviene separar dos propiedades que a veces se confunden. Una es el orden de los eventos: qué pasó antes y qué después. La otra es el valor absoluto del reloj: la fecha y hora concretas. La cadena de hash, por su encadenamiento, garantiza fuertemente el orden: no se puede insertar un evento "entre medio" ni reordenar la secuencia sin romper el encadenamiento, independientemente de lo que diga cualquier reloj. El timestamp del servidor aporta el valor absoluto, que es lo que permite responder "¿en qué fecha exactamente?". Las dos propiedades se complementan: el encadenamiento asegura la secuencia, el sello asegura la ubicación en el calendario. Por eso atacar la cronología de un registro así no es cuestión de cambiar una fecha: habría que falsificar el sello y, además, rehacer toda la cadena posterior de forma consistente. Esa combinación es lo que vuelve creíble la línea de tiempo frente a alguien que parte de la desconfianza.

Es fácil subestimar este punto porque suena menor: ¿quién pone la fecha? Pero es la diferencia entre una bitácora y una prueba, y los marcos de integridad de datos más exigentes del mundo lo tratan como un requisito, no como una opción. Para una asociación, esa distinción no es teórica: aparece, con todo su peso, el día que la cronología deja de ser un detalle y pasa a ser exactamente lo que se discute.