Marcas de tiempo Unix negativas: antes de 1970

La mayoría de la gente conoce el tiempo Unix como un número grande y siempre creciente — el tipo de valor que ves en una línea de registro o una columna created_at. Así que es una sorpresa común la primera vez que aparece un -1234567890 en algún sitio y el parser lo resuelve a una fecha de los años 30 o lanza un error. Ninguna de las dos reacciones tiene realmente que ver con que el número esté mal. El tiempo Unix se definió como un conteo con signo desde un punto cero fijo, y un conteo con signo puede ser negativo. Esta guía cubre qué significa una marca de tiempo negativa, dónde te las encuentras realmente, y por qué algo de código se atraganta con algo que el formato ha soportado desde el principio.

Qué significa realmente una marca de tiempo negativa

Una marca de tiempo Unix es el número de segundos transcurridos desde las 00:00:00 UTC del 1 de enero de 1970 — el epoch. POSIX (IEEE Std 1003.1) define el tipo subyacente, time_t, como un entero con signo contado relativo a el epoch, no contado hacia arriba desde él. Los conteos relativos van en ambas direcciones: un valor positivo son esos muchos segundos después del epoch, y un valor negativo son esos muchos segundos antes de él. No hay nada especial en que cero sea un suelo — es solo el punto de referencia, de la misma forma que 0 °C es un punto de referencia y no la temperatura más fría posible.

Así que una marca de tiempo negativa se resuelve exactamente como esperarías:

El patrón es lineal en ambas direcciones: cada segundo antes del epoch resta uno al conteo, exactamente igual que cada segundo después de él suma uno. No hay ninguna discontinuidad en cero de la que preocuparse.

Dónde aparecen realmente las marcas de tiempo negativas

No necesitas datos históricos para encontrarte con una. Las fuentes más comunes en el mundo real son:

Fechas de nacimiento y otros registros anteriores a 1970. Cualquier sistema que almacene fechas de nacimiento, eventos históricos o registros de archivo como segundos de epoch producirá valores negativos para cualquiera nacido antes de 1970 — que, a partir de 2026, es la mayoría de los adultos mayores de 56 años.

Valores predeterminados o centinela. Algunas bases de código usan 0 o un número negativo pequeño como marcador de «sin establecer», que luego se interpreta erróneamente como una fecha real en lugar de un centinela — un error, pero uno que depende de que los valores negativos sean analizables en primer lugar, no de que sean inválidos.

Desfase de reloj y fixtures de prueba. Un cliente con un reloj de sistema muy desajustado, o una prueba unitaria que elige deliberadamente una fecha de caso límite, puede generar un valor negativo mucho antes del epoch sin que nadie pretendiera datos históricos en absoluto.

Por qué algunas herramientas las rechazan de todos modos

El rechazo es casi siempre una decisión de implementación, no un requisito de la especificación. Tres patrones explican la mayor parte:

Algunos sistemas más antiguos o embebidos usaron un entero sin signo para time_t en lugar del con signo de POSIX, ya sea para duplicar el rango futuro o porque la plataforma nunca esperó fechas anteriores a 1970. Un tipo sin signo simplemente no tiene representación para números negativos — es una decisión de almacenamiento, no relacionada con lo que se le permite significar al tiempo Unix.

Algunas validaciones de formularios o esquemas de API añaden una regla como timestamp >= 0 porque se espera que el campo solo contenga valores «de ahora» (una hora de inicio de sesión, una hora de petición), y el autor nunca consideró que el tipo también se reutilizaría para una fecha de nacimiento o un campo histórico.

Y algunos parsers se escribieron y probaron exclusivamente contra valores recientes y positivos, así que uno negativo ejercita una ruta de código — normalmente el análisis de cadena a número, o la detección de unidad basada en cantidad de dígitos como «16 dígitos significa microsegundos» — que nadie comprobó contra un signo menos inicial.

Nada de esto significa que la marca de tiempo en sí esté mal formada. Si controlas el esquema, la solución es usar un tipo con signo de 64 bits (que ya es el predeterminado en todo lenguaje y base de datos convencional) y eliminar la restricción arbitraria >= 0 a menos que el campo genuinamente nunca pueda ser histórico.

Convertir correctamente una marca de tiempo negativa

La matemática de conversión es idéntica a la de una marca de tiempo positiva — multiplica por 1000 para pasar de segundos a milisegundos si el constructor de fecha de tu lenguaje espera milisegundos (la mayoría lo hace: el Date de JavaScript, por ejemplo, acepta valores en milisegundos en un rango de aproximadamente ±8,64 × 10¹⁵, cubriendo cómodamente cualquier valor negativo que vayas a encontrar realmente). La única diferencia práctica es la detección de unidad por cantidad de dígitos, que es cómo muchas herramientas de marcas de tiempo (incluida la nuestra) adivinan segundos frente a milisegundos frente a microsegundos: hay que quitar un signo menos inicial antes de contar dígitos, y luego reaplicarlo al resultado. Hecho correctamente, una marca de tiempo negativa va y vuelve a través de ISO 8601 exactamente igual que una positiva — consulta nuestra guía de epoch y precisión para saber cómo funciona esa detección por cantidad de dígitos.

La versión corta

Una marca de tiempo Unix negativa no es un estado de error — es el formato funcionando exactamente como se especificó, contando hacia atrás desde un punto cero fijo en lugar de hacia adelante. Si tu propio código rechaza valores negativos, es una regla de validación que añadiste tú, no un límite del formato. Y si una herramienta de terceros los rechaza, la solución suele ser cambiar a una, como un conversor de epoch con signo de 64 bits, que sí se probó realmente contra entradas anteriores a 1970.