Timestamp Unix explicado: segundos, milisegundos y el año 2038

Un timestamp Unix es solo el número de segundos desde el 1 de enero de 1970 a las 00:00:00 UTC. Esa sencillez explica que esté en todas partes, y también que el mismo número dé una fecha equivocada por cincuenta años si confundes segundos con milisegundos.

Revisado el 3 de octubre de 2026 · 4 min de lectura

Qué significa el número

Un timestamp Unix (o «tiempo epoch») cuenta los segundos transcurridos desde la época Unix: las 00:00:00 UTC del 1 de enero de 1970. El timestamp 0 es ese instante exacto; 1.000.000.000 es el 9 de septiembre de 2001 a las 01:46:40 UTC; 1.700.000.000 es el 14 de noviembre de 2023 a las 22:13:20 UTC. Para el 3 de octubre de 2026 a las 00:00:00 UTC, el valor es 1.790.985.600.

POSIX, el estándar que lo define, dice que el valor aproxima el número de segundos transcurridos desde la época, y que cada día se contabiliza como exactamente 86.400 segundos. Ese último detalle implica que los segundos intercalares no se cuentan: el timestamp es una cuenta ordenada de días por 86.400 más los segundos del día, y por eso la aritmética de fechas con él es tan fácil.

Como se cuenta desde un instante fijo en UTC, un timestamp no tiene zona horaria. 1700000000 es el mismo instante en Madrid, Nueva York o Tokio; lo único que cambia es cómo se muestra. Esa es la razón principal por la que los sistemas guardan timestamps y convierten a la hora local solo al mostrarlos.

¿Segundos o milisegundos? Cuenta las cifras

El error clásico. Cada sistema usa una unidad:

  • Segundos (10 cifras en este momento): las herramientas de Unix y Linux, la mayoría de bases de datos y API, time.time() de Python (con decimales) y time() de PHP.
  • Milisegundos (13 cifras): Date.now() y new Date(ms) de JavaScript, System.currentTimeMillis() de Java.

Si los mezclas, la fecha sale muy equivocada. En JavaScript, new Date(1700000000) lee el número como milisegundos y devuelve el 20 de enero de 1970, mientras que new Date(1700000000 * 1000) da el 14 de noviembre de 2023, que era lo que querías. Al revés, tratar como segundos un valor de 13 cifras en milisegundos te lleva miles de años al futuro. Regla rápida para fechas actuales: 10 cifras son segundos, 13 son milisegundos. El conversor de timestamp reconoce ambos y muestra la fecha en UTC y en tu hora local.

Timestamps y zonas horarias

Un timestamp no es ambiguo; el texto que lo acompaña, sí. Si un formulario dice «2026-10-25 02:30» sin desfase, ¿qué instante es? En Europa, la noche en que se atrasan los relojes, las 02:30 ocurren dos veces. Cuando necesites intercambiar una hora como texto, usa ISO 8601 con desfase o con Z para UTC, por ejemplo 2026-10-03T00:00:00Z o 2026-10-03T02:00:00+02:00. El conversor a ISO 8601 convierte un timestamp o una fecha local a ese formato. Y para ver qué hora es en otro lugar en ese mismo instante, el conversor de zonas horarias se ocupa de los desfases y del horario de verano.

El problema del año 2038

Si un sistema guarda el timestamp como un entero de 32 bits con signo, el valor máximo que cabe es 2.147.483.647. Eso es el 19 de enero de 2038 a las 03:14:07 UTC. Un segundo después, el contador se desborda y pasa a un número negativo muy grande, que un sistema ingenuo lee como una fecha de diciembre de 1901. Es el «problema del año 2038», el equivalente Unix del efecto 2000.

La mayoría de sistemas modernos usan ya timestamps de 64 bits, que no se desbordan en unos 292.000 millones de años, así que un portátil o un móvil no corre riesgo. Los que sí pueden tenerlo son dispositivos empotrados antiguos, formatos de archivo o columnas de bases de datos que siguen en 32 bits. Un valor de 32 bits sin signo alarga el límite hasta el 7 de febrero de 2106, a costa de no poder representar fechas anteriores a 1970. Si diseñas un esquema hoy, usa un entero de 64 bits o un tipo de fecha y hora propiamente dicho.

Fechas anteriores a 1970 y otros casos límite

  • Valores negativos son fechas anteriores a la época: -1 es el 31 de diciembre de 1969 a las 23:59:59 UTC. POSIX deja sin definir la relación para años anteriores a 1970, pero la mayoría del software actual maneja bien los negativos.
  • Segundos intercalares: se ignoran, como se ha explicado. En la práctica el reloj del sistema repite un segundo o lo «reparte»; el timestamp nunca marca 23:59:60.
  • Fracciones de segundo se escriben con decimales (1700000000.123) o como milisegundos o microsegundos con más cifras.

Conversiones útiles

  • Un día son 86.400 segundos; una semana, 604.800.
  • Para sumar 30 días a un timestamp en segundos, suma 30 × 86.400 = 2.592.000. Ojo: son exactamente 30 días de 24 horas, no «un mes natural», y no mantienen «la misma hora local» si entre medias hay un cambio de hora.
  • Para pasar de milisegundos a segundos, divide entre 1.000; para lo contrario, multiplica.

Para ver cómo afecta el horario de verano a las fechas, mira el cambio de hora en España; y para el número de semana de una fecha, cómo funcionan las semanas ISO.

Fuentes y más información

Datos comprobados el 3 de octubre de 2026.

Hazlo ahora, gratis y en tu navegador. Tus archivos no se suben.

Convierte marcas de tiempo epoch en fechas y fechas en marcas de tiempo, en segundos o milisegundos.

Preguntas frecuentes

¿Qué es un timestamp Unix?
El número de segundos transcurridos desde las 00:00:00 UTC del 1 de enero de 1970 (la época Unix). No tiene zona horaria: identifica un único instante.
¿Cómo distingo segundos de milisegundos?
Por la longitud, en fechas actuales: 10 cifras son segundos y 13 son milisegundos. JavaScript y Java usan milisegundos; las herramientas Unix, PHP y la mayoría de bases de datos usan segundos.
¿Por qué mi timestamp da una fecha de 1970?
Porque un valor en segundos se ha leído como milisegundos. En JavaScript, new Date(1700000000) da el 20 de enero de 1970; multiplica por 1000 para obtener la fecha buscada.
¿Qué es el problema de 2038?
Un timestamp de 32 bits con signo se desborda tras 2.147.483.647, que es el 19 de enero de 2038 a las 03:14:07 UTC. Los sistemas que lo siguen guardando en 32 bits leerán mal la fecha. Los de 64 bits no se ven afectados.
¿Incluye un timestamp Unix los segundos intercalares?
No. POSIX cuenta cada día como exactamente 86.400 segundos, así que los segundos intercalares no están representados.