Qué es un Unix Timestamp y Cómo Convertirlo
Un Unix timestamp es el número de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 UTC, el instante conocido como Unix epoch. Es la forma en que la inmensa mayoría de sistemas informáticos guardan y transmiten una fecha y hora: un solo número entero en lugar de una cadena de texto con día, mes, año y zona horaria. Si alguna vez viste un valor como 1700000000 en la columna created_at de una fila de base de datos, eso es exactamente lo que es: un instante concreto codificado como segundos desde el epoch.
Qué es realmente un Unix timestamp
El epoch, 1 de enero de 1970 a medianoche UTC, funciona como el punto cero de una recta numérica. Cada segundo que pasa suma 1 a ese contador. El mediodía de hoy es un número mayor que el mediodía de ayer, y la diferencia entre ambos, en segundos, se obtiene con una simple resta. Esa es la razón por la que las computadoras prefieren este formato en lugar de una fecha escrita: comparar, ordenar o calcular la diferencia entre dos cadenas como “14/11/2023 22:13:20” y “18/05/2033 03:33:20” exige parsear texto y tener en cuenta meses, años bisiestos y formatos regionales. Restar dos enteros es instantáneo y no admite ambigüedad.
También resuelve el problema de la zona horaria en el origen. Un timestamp no tiene zona horaria propia, es un instante absoluto, el mismo para cualquier persona en cualquier parte del planeta. Eso lo hace ideal para columnas de tipo created_at en una base de datos, para el claim exp de un JWT que marca cuándo expira un token, o para una línea de log que registra cuándo ocurrió un evento en un servidor que puede estar en otro continente que quien lo lee.
Ejemplo práctico: cómo leer valores de timestamp reales
La tabla siguiente muestra cinco valores reales y la fecha UTC exacta a la que corresponden.
| Unix timestamp (segundos) | Fecha y hora UTC |
|---|---|
| 0 | 1 de enero de 1970, 00:00:00 UTC (el epoch mismo) |
| 1000000000 | 9 de septiembre de 2001, 01:46:40 UTC |
| 1700000000 | 14 de noviembre de 2023, 22:13:20 UTC |
| 2000000000 | 18 de mayo de 2033, 03:33:20 UTC |
| 2147483647 | 19 de enero de 2038, 03:14:07 UTC |
Tomemos 1700000000 como ejemplo de cómo se llega a esa fecha sin hacer la aritmética completa a mano. Un año tiene aproximadamente 31.536.000 segundos (365 × 86400), así que dividir 1700000000 entre esa cifra da algo más de 53 años desde 1970, lo cual aterriza cerca de finales de 2023. El resto de esa división, ajustado por los años bisiestos que se acumulan en más de cinco décadas, es lo que ubica el instante exacto en el 14 de noviembre a las 22:13:20 UTC. No hace falta memorizar el cálculo, pero sirve para entender por qué un número que a simple vista parece arbitrario cae exactamente en un día y una hora concretos.
¿Segundos o milisegundos? Cómo diferenciarlos
Este es el error más frecuente al trabajar con timestamps. Un timestamp en segundos tiene hoy 10 dígitos, como 1700000000. El mismo instante expresado en milisegundos tiene 13 dígitos: 1700000000000, que sigue siendo el 14 de noviembre de 2023, solo que multiplicado por 1000.
El método Date.now() de JavaScript y buena parte de las APIs web devuelven milisegundos por convención. En cambio, las llamadas al sistema de Unix, cron y la mayoría de las herramientas de línea de comandos de Linux trabajan en segundos. Pegar un valor en milisegundos dentro de un campo que espera segundos multiplica el resultado por mil y te manda al futuro lejano: 1700000000000 interpretado como segundos no cae en 2023, sino en el año 55.860 aproximadamente. Si un conversor te devuelve una fecha absurda, casi siempre el problema es ese factor de 1000 mal aplicado en una dirección o en la otra.
Convertir un timestamp a una fecha
Si tienes un valor como el de un log de errores o el created_at de un registro y necesitas saber a qué momento corresponde, pégalo aquí abajo y verás el resultado en UTC, en tu hora local y en formato ISO 8601 al instante.
Convertir una fecha a un timestamp
El caso inverso también es habitual: programar algo para una fecha y hora concretas, por ejemplo un cron job que debe dispararse el 25 de diciembre a medianoche, o construir el parámetro de una API que solo acepta enteros. Elige la fecha y la hora, decide si trabajas en UTC o en tu zona horaria local, y obtén el timestamp listo para pegar en tu código o en tu consulta.
Errores comunes y casos límite
Confundir segundos con milisegundos. Ya se explicó arriba, pero merece repetirse porque es la causa número uno de fechas que “no tienen sentido” al depurar código. Antes de sospechar de tu lógica, cuenta los dígitos: 10 son segundos, 13 son milisegundos.
El problema del año 2038. Los sistemas que almacenan el timestamp como un entero de 32 bits con signo alcanzan su valor máximo en 2147483647, que corresponde al 19 de enero de 2038 a las 03:14:07 UTC. Un segundo después, ese contador desborda y se convierte en un número negativo, lo que rompe cualquier lógica de fechas que dependa de él. Los sistemas modernos de 64 bits no tienen esta limitación, porque su rango alcanza para representar fechas miles de millones de años hacia el futuro.
Confusión de zona horaria. Un Unix timestamp no lleva zona horaria incorporada, es un instante absoluto. La confusión aparece al mostrarlo: dos personas en zonas horarias distintas que miran el mismo timestamp verán relojes distintos (una en UTC-3, otra en UTC+1, por ejemplo), pero ambas están viendo exactamente el mismo instante en el tiempo. El timestamp nunca cambia, lo que cambia es cómo decides presentarlo.
Timestamps negativos. Un valor negativo representa una fecha anterior al 1 de enero de 1970. Por ejemplo, -86400 corresponde al 31 de diciembre de 1969, exactamente 24 horas antes del epoch. No todas las herramientas ni todos los sistemas admiten valores negativos, así que si necesitas trabajar con fechas históricas conviene verificarlo antes de depender de esa funcionalidad.
Preguntas frecuentes
¿Qué es un Unix timestamp? Es el número total de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 UTC, el Unix epoch. Se usa en programación para representar un instante exacto sin ninguna ambigüedad respecto a la zona horaria.
¿Cómo sé si mi timestamp está en segundos o en milisegundos? Cuenta los dígitos. En la fecha actual, un timestamp en segundos tiene 10 dígitos (por ejemplo 1700000000). Uno en milisegundos tiene 13 (1700000000000). Si el número parece demasiado grande o la fecha resultante cae en un futuro absurdo, casi siempre es una confusión entre ambas unidades.
¿Qué es el problema del año 2038? Es el desbordamiento que sufren los sistemas que guardan el timestamp como un entero de 32 bits con signo: el máximo valor representable es 2147483647, correspondiente al 19 de enero de 2038 a las 03:14:07 UTC. Al superarlo, el contador se vuelve negativo y rompe cualquier cálculo de fechas que dependa de él. Los sistemas de 64 bits no tienen este límite práctico.
¿Puedo convertir una fecha anterior a 1970? Sí. Esas fechas se representan con timestamps negativos. El 31 de diciembre de 1969, por ejemplo, es -86400. No todas las herramientas admiten valores negativos, así que conviene comprobarlo si trabajas con fechas históricas.
¿Por qué las bases de datos guardan fechas como Unix timestamp en lugar de una cadena de texto? Porque un entero es mucho más compacto, no depende de ningún idioma ni formato regional, y permite comparar, ordenar y calcular diferencias entre fechas con simple aritmética en lugar de parsear texto. Además, al no tener zona horaria propia, el mismo valor significa exactamente lo mismo sin importar en qué servidor o país se procese.