Convertidor de Timestamp Unix

Marcas de tiempo Unix sin dolores de cabeza

Pregunta a tres desarrolladores qué hora es y podrías obtener tres respuestas, según dónde se encuentren. Pregunta a una marca de tiempo Unix (Unix timestamp) y obtienes exactamente un número, el mismo para todo el mundo en el planeta. Ese único entero es la razón por la que el tiempo epoch sostiene de forma silenciosa casi todos los archivos de registro, filas de base de datos y respuestas de API que llegarás a manejar. Esta página explica qué significa ese número, cómo leerlo en ambos sentidos y dónde suele dar problemas a la gente.

Qué es realmente el tiempo Unix

Una marca de tiempo Unix es el número de segundos transcurridos desde las 00:00:00 UTC del 1 de enero de 1970, sin contar los segundos intercalares. Ese momento se denomina epoch, y los primeros ingenieros de Unix lo eligieron sencillamente porque era una fecha redonda y cómoda desde la cual contar. En el epoch el valor es exactamente 0. Cada segundo desde entonces suma uno, así que el número solo crece. Las fechas anteriores a 1970 también son perfectamente válidas, expresadas como enteros negativos.

También verás este concepto llamado tiempo POSIX o, de forma imprecisa, tiempo epoch. Sea cual sea la etiqueta, la mecánica es la misma: un único contador de segundos en constante aumento. Como es un entero simple en lugar de una cadena con formato, una computadora puede almacenarlo en unos pocos bytes y comparar dos de ellos con una sola resta.

Segundos, milisegundos y compañía

El tiempo Unix clásico cuenta segundos enteros, lo que da el familiar número de diez dígitos que ves hoy. Pero muchos entornos necesitan una resolución más fina. JavaScript, por ejemplo, trabaja en milisegundos, produciendo un valor de trece dígitos, y algunos sistemas van más allá hasta microsegundos o nanosegundos. Una regla práctica fiable: un número de diez dígitos son segundos, trece dígitos son milisegundos. Si tu fecha convertida cae en algún punto cercano a 1970 cuando esperabas el día de hoy, casi con seguridad introdujiste milisegundos en un campo de segundos, o al revés. Nuestro conversor detecta automáticamente la magnitud, así que rara vez tienes que adivinar.

Por qué los desarrolladores se apoyan en ella

La gran ventaja es que una marca de tiempo es neutral respecto a la zona horaria. El entero 1735689600 se refiere al mismo instante en Tokio, Berlín y São Paulo. Almacenar ese número en lugar de una cadena local con formato significa que nunca tienes que preguntarte a qué reloj pertenecía un valor. La ordenación también es trivial, porque el orden cronológico no es más que orden numérico, de modo que un índice de base de datos sobre una columna de marca de tiempo ordena los eventos correctamente sin necesidad de análisis. La aritmética es igual de limpia: la diferencia entre dos eventos es una sola resta, y añadir un día es sumar 86400. Estas propiedades son exactamente por las que los registros, los tokens, las cachés y las colas de mensajes recurren al tiempo epoch.

Convertir en ambos sentidos

Pasar de una marca de tiempo a una fecha legible para humanos consiste en tomar el conteo de segundos y proyectarlo sobre un calendario, para luego darle formato en la zona horaria que te interese. En el sentido inverso, tomas un año, un mes, un día y una hora, decides en qué zona horaria está expresada y la reduces de nuevo a segundos desde el epoch. Nuestra herramienta hace ambos sentidos al instante y por completo en tu navegador, de modo que nada de lo que pegas sale de tu equipo. Pega un número para decodificarlo, o elige una fecha para codificarla, y lee el resultado en UTC y en tu hora local en el mismo momento.

UTC frente a hora local, la trampa clásica

La marca de tiempo en sí no tiene zona horaria; siempre está anclada a UTC. La confusión aparece únicamente cuando la muestras. Si conviertes 1700000000 y tu pantalla muestra una hora de la tarde-noche mientras un colega de otro país ve una hora de la tarde, nada está roto: ambos miráis el mismo instante representado en relojes locales distintos. Los errores se cuelan cuando el código lee una fecha local como si fuera UTC, o estampa una hora de reloj de pared sin registrar el desfase. El hábito seguro es almacenar y transmitir en UTC, y aplicar un desfase local solo en el último momento, cuando muestras el valor a una persona. En caso de duda, compara con la línea UTC del conversor en lugar de con la local.

El problema del año 2038

Muchos sistemas antiguos almacenaban el tiempo Unix en un entero de 32 bits con signo. Ese campo se queda sin espacio un segundo después de las 03:14:07 UTC del 19 de enero de 2038, cuando el contador se desborda y da la vuelta hasta un número negativo, lo que podría arrojar las fechas de vuelta a 1901. Es el mismo tipo de problema que el Y2K. La buena noticia es que los sistemas operativos y lenguajes modernos han pasado en gran medida a marcas de tiempo de 64 bits, que no se desbordarán durante unos 292 mil millones de años, así que para el código nuevo es sobre todo una curiosidad histórica que conviene conocer más que una emergencia.

Para más ayudantes basados en el navegador consulta nuestras herramientas para desarrolladores, y si necesitas operar con los números en sí, las calculadoras están a un clic.

Preguntas frecuentes