El tiempo Unix en una frase
El tiempo Unix, también llamado tiempo epoch o tiempo POSIX, es un único número entero que cuenta segundos desde la época, 1970-01-01T00:00:00Z. No contiene zona horaria, horario de verano ni calendario, y por eso lo usan bases de datos, archivos de registro, API, tokens JWT y sistemas de archivos: dos servidores en continentes distintos escriben el mismo número para el mismo instante.
Las fechas anteriores a 1970 son números negativos: -1 es el 31 de diciembre de 1969 a las 23:59:59 UTC. El valor actual está un poco por debajo de dos mil millones y crece 86.400 cada día.
Pruébalo aquí: Convertidor de timestamp Unix
Abrir la herramienta completaSegundos, milisegundos, microsegundos
La definición usa segundos, pero muchos sistemas guardan unidades más finas y lo siguen llamando timestamp Unix. En 2026 la forma más rápida de distinguirlas es contar los dígitos, que es también como el convertidor de esta página detecta la unidad.
Confundirlas es el error más común: si lees milisegundos como segundos obtienes una fecha unos 54.000 años en el futuro; si lees segundos como milisegundos caes en enero de 1970. Si la fecha convertida muestra 1970, multiplica por 1.000. Si muestra un año lejanísimo, divide entre 1.000.
| Unidad | Dígitos hoy | Ejemplo del mismo instante | Fuentes habituales |
|---|---|---|---|
| Segundos | 10 | 1700000000 | Unix y Linux, PHP time(), MySQL UNIX_TIMESTAMP(), exp e iat de JWT |
| Milisegundos | 13 | 1700000000000 | JavaScript Date.now(), Java System.currentTimeMillis(), muchas API JSON |
| Microsegundos | 16 | 1700000000000000 | Funcionamiento interno de PostgreSQL, algunas herramientas de Python y bases de datos |
| Nanosegundos | 19 | 1700000000000000000 | Go time.UnixNano(), trazas de alta resolución |
Zonas horarias y UTC
El timestamp siempre se basa en UTC; las zonas horarias solo aparecen al convertirlo en una fecha de calendario para que la lea una persona. El mismo valor 1700000000 son las 23:13 en Madrid, las 19:13 en Buenos Aires y las 16:13 en Ciudad de México. El número no cambia, solo cómo se muestra.
Por eso lo recomendable es guardar timestamps (o fechas UTC) y pasar a hora local en el último paso, en la interfaz. Guardar horas locales provoca horas duplicadas o perdidas cuando cambia el horario de verano. El convertidor muestra cada timestamp en tu hora local, en UTC y en una zona extra que elijas en Mostrar también en, además de ISO 8601 (2023-11-14T22:13:20.000Z) para API y RFC 2822 para cabeceras de correo.
Un detalle: el tiempo Unix ignora los segundos intercalares. Cada día tiene exactamente 86.400 segundos, así que un timestamp se convierte en fecha con aritmética simple.
Convertir en Excel y Google Sheets
Las hojas de cálculo cuentan días desde 1900 en lugar de segundos desde 1970, así que divides entre los segundos de un día y sumas la fecha de la época. En Excel en español la función se llama FECHA; el separador de argumentos es punto y coma o coma según tu configuración regional. Da formato de Fecha u Hora a la celda del resultado, o verás un número decimal como 45244,93.
El resultado está en UTC. Para la hora local suma la diferencia en horas dividida entre 24, por ejemplo -5/24 para Bogotá o -6/24 para Ciudad de México, que no cambian de hora. Excel no sabe nada del horario de verano, así que en países como España una diferencia fija falla medio año; para registros grandes usa el modo en lote del convertidor.
| Tarea | Fórmula (timestamp en A2) |
|---|---|
| Segundos a fecha (UTC) | =A2/86400+FECHA(1970;1;1) |
| Milisegundos a fecha (UTC) | =A2/86400000+FECHA(1970;1;1) |
| Segundos a hora de Bogotá (UTC-5) | =A2/86400+FECHA(1970;1;1)-5/24 |
| Fecha de A2 a segundos | =(A2-FECHA(1970;1;1))*86400 |
| La misma fórmula en Excel en inglés | =A2/86400+DATE(1970,1,1) |
Convertir en JavaScript, Python y SQL
Todos los lenguajes y bases de datos importantes traen funciones para esto. Fíjate en la unidad que espera cada una: JavaScript trabaja en milisegundos y casi todos los demás en segundos.
| Entorno | Timestamp actual | De timestamp a fecha |
|---|---|---|
| JavaScript | Math.floor(Date.now() / 1000) | new Date(ts * 1000).toISOString() |
| Python | int(time.time()) | datetime.fromtimestamp(ts, tz=timezone.utc) |
| PHP | time() | gmdate('Y-m-d H:i:s', $ts) |
| MySQL | UNIX_TIMESTAMP() | FROM_UNIXTIME(ts) |
| PostgreSQL | extract(epoch from now()) | to_timestamp(ts) |
| SQL Server | DATEDIFF_BIG(SECOND, '1970-01-01', SYSUTCDATETIME()) | DATEADD(SECOND, ts, '1970-01-01') |
| SQLite | strftime('%s', 'now') | datetime(ts, 'unixepoch') |
El problema del año 2038
Muchos sistemas antiguos guardan el tiempo Unix como un entero de 32 bits con signo. Su valor máximo es 2.147.483.647, al que se llega el 19 de enero de 2038 a las 03:14:07 UTC. Un segundo después el número se desborda a un valor negativo grande y la fecha salta a diciembre de 1901. Todo lo que calcule fechas futuras, como préstamos a 20 años, certificados o tareas programadas, puede toparse con el límite antes.
Los sistemas operativos, lenguajes y bases de datos actuales usan tiempo de 64 bits, que alcanza para miles de millones de años. El riesgo está en dispositivos embebidos antiguos, formatos de archivo y columnas de bases de datos. En MySQL, por ejemplo, el tipo de columna TIMESTAMP sigue terminando en enero de 2038, así que los datos de larga vida están más seguros en DATETIME o BIGINT. Si mantienes código antiguo, busca campos de tiempo de 32 bits y columnas int que guarden timestamps.
Valores de referencia útiles
- 0 = 1970-01-01 00:00:00 UTC, la propia época.
- 1000000000 = 2001-09-09 01:46:40 UTC, el primer timestamp de diez dígitos.
- 1700000000 = 2023-11-14 22:13:20 UTC.
- 2000000000 = 2033-05-18 03:33:20 UTC.
- 2147483647 = 2038-01-19 03:14:07 UTC, el límite de 32 bits.
- 86400 = un día, 604800 = una semana, 3600 = una hora.