Qué es un Unix timestamp, en cristiano
Es un contador. Un cronómetro que empezó a correr el 1 de enero de 1970 a medianoche y no ha parado desde entonces. Cada segundo que pasa suma uno. Esa es la idea entera.
El número 1746792000 significa “1.746.792.000 segundos después de aquel momento de salida”. Lo metes en cualquier herramienta decente de fechas y te sale una fecha real, 9 de mayo de 2026.
A los ordenadores les encanta porque un único entero no admite ambigüedad. Dos sistemas en cualquier punto del planeta, dado el mismo número, coinciden en el mismo instante exacto. Eso en software es rarísimo.
Por qué el mismo número muestra horas distintas
Tú y un amigo en Tokio miráis 1746792000 a la vez. Tu pantalla dice 2 de la tarde, hora de Madrid. La suya dice 9 de la noche, hora de Tokio. Mismo instante, relojes de pared distintos.
El número en sí no cambia nunca. Lo que cambia es cómo decide mostrarlo cada dispositivo. Nueva York lo retrasa 6 horas, Londres lo deja igual, Tokio lo adelanta 9.
Guarda siempre las fechas como el número crudo. Muéstralas en la zona horaria que le importe al lector. Si guardas “9 de mayo a las 2 de la tarde” sin decir de qué ciudad, has perdido. Seis meses después nadie recuerda si era hora UTC, hora de servidor o lo que tuviera el portátil.
El bug que muerde la mitad de las fechas: segundos o milisegundos
Algunos sistemas cuentan en segundos. Otros cuentan en milisegundos, mil veces más. Los números se parecen muchísimo hasta que los lees como fecha.
1746792000 en segundos es mayo de 2026. El mismo número leído como milisegundos se convierte en el 21 de enero de 1970, justo después de medianoche. El proyecto entero muestra la edad de tus usuarios como si hubieran nacido la semana pasada.
La diferencia se ve a ojo. Un timestamp actual en segundos tiene 10 dígitos. En milisegundos tiene 13. Cualquier cosa en medio probablemente está mal.
Cuando un sistema te da un timestamp y la documentación no dice cuál es, pégalo en el convertidor de timestamps de AldeaCode. Detecta la unidad, te muestra la fecha en tu zona horaria y en UTC a la vez, y no manda el valor a ninguna parte. Útil cuando un contrato de API solo dice “epoch” y te toca adivinar.
Cómo se manejan en navegadores y JavaScript
Tres líneas que vas a teclear cien veces.
Math.floor(Date.now() / 1000); // timestamp actual en segundos
new Date(1746792000 * 1000).toISOString(); // timestamp a string UTC legible
new Date("2026-05-09T12:00:00Z").getTime(); // string a milisegundosEl patrón: JavaScript habla en milisegundos, casi todo lo demás habla en segundos. Multiplica o divide por 1000 en la frontera. Eso es la mitad del trabajo de fechas que vas a hacer en tu vida.
Cuando escribas una fecha como string, mete siempre la Z al final (significa UTC) o un offset explícito tipo +02:00. Una cadena de fecha sin nada al final es el segundo bug clásico, porque cada navegador la interpreta a su manera.
Una bomba de relojería de hace 12 años que vas a querer conocer
En enero de 2038, una forma vieja de guardar timestamps se desbordará. Código de los años 90 que usa enteros de 32 bits empezará a decir que estamos en 1901 en lugar de 2038. Bancos, sistemas de nóminas, chips embebidos y bases de datos antiguas todavía sufren esto.
El arreglo es una línea: usa un entero más grande (64 bits) para la columna. La mayoría de sistemas modernos lo hicieron hace 20 años. Algunos no. Si mantienes algo anterior a 2010, busca columnas INT que guarden fechas y pásalas a BIGINT antes de que lo descubra otro.
Esto no es teoría. La fecha tope es real, está fijada, y no hay prórroga.
Referencia rápida para los lenguajes habituales
# Bash
date -u +%s # timestamp actual
date -u -d @1746792000 +%FT%TZ # timestamp a string UTC
# Python
import time; int(time.time())
# PostgreSQL
SELECT EXTRACT(EPOCH FROM NOW())::BIGINT;
SELECT TO_TIMESTAMP(1746792000) AT TIME ZONE 'UTC';
# Go
time.Now().Unix();
time.Unix(1746792000, 0).UTC();Todos trabajan en segundos. Ninguno sabe en qué zona horaria quieres mostrar el resultado, esa decisión la tomas tú al final. Si vives dentro de una base de datos, el convertidor de timestamps para PostgreSQL y el convertidor para MySQL muestran los snippets equivalentes de TO_TIMESTAMP y FROM_UNIXTIME junto a una conversión en vivo.
Cuando solo quieres inspeccionar un timestamp sin ponerte a programar, el convertidor de timestamps lo hace al instante. Combínalo con el formateador JSON cuando el timestamp viene metido en un payload, y con el generador de UUIDs si estás montando un registro desde cero. Tres reglas y ya está: guarda el número crudo, respeta la diferencia entre segundos y milisegundos, y elige la zona horaria en el momento de mostrar.