Convertidor de Timestamp Unix
Convierte epochs Unix a fechas legibles y viceversa.
100% en tu navegador — no se sube nadaConvertir un timestamp Unix a fecha
Ejemplo cargado: 1767225600 = 1 de enero de 2026, 00:00 UTC
Sobre este convertidor de timestamp Unix
Un timestamp Unix cuenta segundos desde el 1 de enero de 1970 UTC: es la forma en que bases de datos, logs y APIs suelen guardar el tiempo. Pega uno y ve la fecha legible en tu zona horaria local, en UTC y en ISO 8601. La herramienta detecta automáticamente si tu valor está en segundos o milisegundos.
También funciona a la inversa: elige fecha y hora, y obtén el epoch en segundos y milisegundos. Un reloj en vivo muestra el timestamp actual, listo para copiar. Un detalle del sentido inverso: el campo de fecha se lee como hora local de tu equipo, así que las 9:00 escritas en San Juan y las 9:00 escritas en Bogotá dan epochs distintos. Es el comportamiento correcto, y es la razón por la que en el sentido directo siempre te mostramos UTC al lado de tu hora local.
La definición formal es corta. POSIX define los "segundos desde el Epoch" con la regla de que cada día se contabiliza con exactamente 86 400 segundos, así que el tiempo Unix ignora a propósito los segundos intercalares. Desde 1972 se han insertado veintisiete en UTC, el último el 31 de diciembre de 2016, y ninguno está en la cuenta: un epoch es un cálculo de calendario, no un conteo de segundos físicos transcurridos. En 2022 la Conferencia General de Pesas y Medidas acordó dejar de insertarlos antes de 2035, con lo que esa diferencia quedará fija.
Que el valor venga en segundos o en milisegundos depende del ecosistema, no del estándar. time() en C, time.time() en Python, Unix() en Go y to_timestamp() en PostgreSQL trabajan en segundos; Date.now() en JavaScript, System.currentTimeMillis() en Java y los timestamps de Kafka trabajan en milisegundos; los formatos de trazas bajan a microsegundos o nanosegundos. La pista más rápida es contar dígitos: hoy un valor tiene 10 dígitos en segundos, 13 en milisegundos, 16 en microsegundos y 19 en nanosegundos. Esta herramienta interpreta como milisegundos todo lo que llegue a 1 000 000 000 000, seguro para cualquier fecha real, pero significa que un valor en microsegundos se lee mal y te deja en el año 57535: divídelo entre 1000 antes de pegarlo.
El problema del año 2038 es la única fecha límite dura del formato. Un entero de 32 bits con signo se detiene en 2 147 483 647, que como segundos desde el epoch es el 19 de enero de 2038 a las 03:14:07 UTC; el segundo siguiente da la vuelta a diciembre de 1901. Escritorios y servidores usan time_t de 64 bits desde hace años y la parte del kernel de Linux para 32 bits se cerró en la versión 5.6, pero cualquier cálculo a largo plazo ya cruzó la línea: un plazo de 30 años firmado en 2008 vence después de 2038. Hay una versión menor fácil de encontrar hoy: hasta SQL Server 2022 el argumento numérico de DATEADD es un int, así que DATEADD(second, 1753488000, ...) funciona pero DATEADD(millisecond, 1753488000000, ...) desborda.
El epoch es el formato equivocado cuando tienes una fecha de calendario y no un instante. Una fecha de nacimiento, la de un contrato o un evento de todo el día no tienen un momento único asociado: guárdalos como DATE y seguirán correctos en cualquier zona horaria. La otra trampa son las citas futuras. Los gobiernos cambian sus desfases con pocos meses de aviso — México eliminó el horario de verano en casi todo el país en 2022 — así que un epoch calculado hoy para una reunión del año que viene queda en la hora equivocada si la regla cambia antes. Guarda la hora local más el identificador de zona IANA.
Convertir un timestamp Unix en Excel y en SQL
Excel no tiene una función que convierta un epoch directamente: hay que hacer la cuenta a mano. Un timestamp son segundos, y Excel guarda las fechas como números de serie en días, donde la parte decimal es la hora. Así que divides entre 86 400 y le sumas la fecha del epoch.
=A1/86400+FECHA(1970;1;1)Si tu Excel usa la coma como separador de argumentos, escribe =A1/86400+FECHA(1970,1,1): el separador depende de tu configuración regional. El resultado queda en UTC; para hora local suma tu desfase en días (Puerto Rico, UTC-4: réstale 4/24). Y si el número tiene 13 dígitos son milisegundos: divide entre 86400000.
| Motor | Consulta |
|---|---|
| PostgreSQL | SELECT to_timestamp(1753488000); |
| MySQL | SELECT FROM_UNIXTIME(1753488000); |
| SQL Server | SELECT DATEADD(second, 1753488000, '1970-01-01'); |
| Oracle | SELECT TO_DATE('1970-01-01','YYYY-MM-DD') + 1753488000/86400 FROM dual; |
Cuidado al comparar motores: to_timestamp devuelve UTC, mientras que FROM_UNIXTIME usa la zona horaria de la sesión de MySQL. Si solo quieres saber qué fecha es un epoch sin abrir una consola ni arrastrar una fórmula, pégalo aquí arriba: sale al instante en hora local, en UTC y en ISO 8601.
Timestamps dinámicos de Discord
Discord convierte <t:UNIX:STYLE> en una fecha que cada persona ve en su propia zona horaria e idioma. La escribes una vez y cada quien la ve en su hora local.
<t:1735689600:F>| Estilo | Lo que muestra |
|---|---|
| t | Hora corta — 20:00 |
| T | Hora larga — 20:00:00 |
| d | Fecha corta — 01/01/2026 |
| D | Fecha larga — 1 de enero de 2026 |
| f | Fecha y hora corta (la que se usa si omites el estilo) |
| F | Fecha y hora larga con el día de la semana |
| R | Relativa — "dentro de 2 horas", "hace 3 días" |
Ojo: el número va en segundos Unix, no en milisegundos. Si pegas un valor de 13 dígitos (milisegundos), Discord muestra un año cercano a 50000. Usa el valor en segundos del cuadro de arriba.
Tablas de referencia
Preguntas frecuentes
¿Segundos o milisegundos, cómo lo sé?
Valores de 10 dígitos (como 1753488000) son segundos; de 13 dígitos son milisegundos. La herramienta lo detecta automáticamente.
¿En qué zona horaria está un timestamp Unix?
En ninguna: siempre es UTC por definición. Las zonas horarias solo importan al mostrarlo, por eso mostramos hora local y UTC.
¿Qué es el problema del año 2038?
Los sistemas que guardan timestamps como enteros de 32 bits con signo se desbordan el 19 de enero de 2038. Los sistemas modernos de 64 bits no se ven afectados.