Convertir timestamp a fecha: tabla de referencia y conversiones SQL

¿Segundos o milisegundos? Cuenta los dígitos

El error más común al manejar epochs es pasarle un valor en milisegundos a una función que espera segundos, lo que te deja aterrizando por el año 58 000. Casi nunca hace falta adivinar: la magnitud del número te dice la unidad. Para cualquier fecha de la época actual, contar dígitos basta para decidir.

Si un valor tiene 13 dígitos y termina en tres ceros, casi seguro son milisegundos generados a partir de una fuente en segundos enteros. Java, JavaScript y Kafka usan milisegundos por defecto; C, Python, Go, PostgreSQL y la shell de Unix usan segundos. Los claims de un JWT (iat, exp, nbf) siempre van en segundos según el RFC 7519, y eso tumba a quien programa en JavaScript, porque Date.now() no.

Conversión por motor de base de datos

Cada motor lo escribe distinto, y las diferencias no son cosméticas: cambian el tipo devuelto y la zona horaria. La columna del centro convierte un epoch en segundos a fecha; la de la derecha hace el camino inverso.

Tres advertencias que causan incidentes reales. El to_timestamp de PostgreSQL devuelve timestamp with time zone, así que se muestra según el parámetro TimeZone del cliente y no en UTC: agrega AT TIME ZONE 'UTC' si necesitas una salida estable. La documentación de MySQL dice que FROM_UNIXTIME devuelve el valor en la zona horaria de la sesión, o sea que la misma consulta le da resultados distintos a dos clientes distintos. Y en SQL Server 2017 hasta 2022 el argumento number de DATEADD es un int, así que DATEADD(MILLISECOND, 1700000000000, ...) se desborda; convierte los milisegundos en dos pasos.

-- SQL Server: milisegundos sin desbordar el int
SELECT DATEADD(MILLISECOND, 1700000000000 % 1000,
         DATEADD(SECOND, 1700000000000 / 1000, '19700101'));

-- PostgreSQL: forzar la salida en UTC
SELECT to_timestamp(1700000000) AT TIME ZONE 'UTC';

Convertir timestamp a fecha en Excel y Google Sheets

Las hojas de cálculo no guardan epochs. Guardan un número de serie de días contado desde el 30 de diciembre de 1899, así que convertir significa dividir entre los segundos que tiene un día y sumar la constante 25569, que es el número de serie del 1 de enero de 1970. Después dale formato de fecha a la celda o solo verás un decimal.

=A1/86400 + 25569          → epoch en segundos a fecha
=A1/86400000 + 25569       → epoch en milisegundos a fecha
=(A1 - 25569) * 86400      → fecha de vuelta a epoch en segundos

La constante 25569 parece arbitraria pero no lo es: incluye un desfase que Excel arrastra a propósito. Excel trata 1900 como año bisiesto, y no lo fue, así que sus números de serie van un día adelantados para cualquier fecha posterior a febrero de 1900. Como 25569 se calculó bajo esa misma suposición equivocada, los dos errores se cancelan y las fechas de 1970 en adelante salen correctas.

Valores epoch notables

Convertir desde código

El problema del año 2038 y otros límites

Un entero de 32 bits con signo se detiene en 2 147 483 647. Un sistema que guarde el tiempo Unix de esa forma se queda sin espacio a las 03:14:07 UTC del 19 de enero de 2038, y al segundo siguiente da la vuelta hasta diciembre de 1901. Esto no es hipotético para dispositivos embebidos, sistemas de archivos viejos y cualquier esquema que haya elegido INT en vez de BIGINT.

La solución no tiene ningún encanto: guarda los epochs en columnas de 64 bits. Una cuenta de segundos en 64 bits con signo se agota dentro de unos 292 000 millones de años, bastante después del punto en que deja de ser tu problema. Si hoy estás eligiendo el tipo de una columna, BIGINT o un tipo timestamp nativo sirven igual; INT es una mina enterrada.

Detalles que conviene tener claros

1. El tiempo Unix ignora los segundos intercalares. POSIX exige que cada día tenga exactamente 86 400 segundos, así que los 27 segundos intercalares insertados en UTC desde 1972 sencillamente no se cuentan. Un epoch es un cálculo de calendario, no un conteo de segundos físicos transcurridos.
2. Un epoch no tiene zona horaria. El número siempre está referido a UTC; la zona horaria solo aparece cuando lo formateas. Si dos servidores muestran fechas distintas para el mismo entero, están formateando distinto, no guardando distinto.
3. Los epochs negativos son válidos y representan fechas anteriores a 1970. Muchas librerías y algunas bases de datos los manejan mal, así que pruébalo si guardas fechas de nacimiento de esta forma.
4. Ojo con los epochs guardados como texto. Ordenar «9999999999» contra «10000000000» de forma lexicográfica los deja al revés, y el error solo aparece cuando cambia la cantidad de dígitos.
5. Un timestamp con resolución de segundos no puede expresar el orden dentro del mismo segundo. Si necesitas secuenciar eventos, guarda milisegundos o agrega una columna de desempate.

Convierte tus propios valores

Esta tabla cubre los valores que la gente consulta una y otra vez, pero no el que tienes ahora mismo en tu archivo de log. El Convertidor de Timestamp Unix de este sitio toma cualquier epoch y te lo muestra a la vez en tu zona horaria local, en UTC y en ISO 8601, detecta solo si pegaste segundos o milisegundos, y hace la conversión al revés desde un selector de fecha. Además mantiene un timestamp actual en vivo listo para copiar. Como todo lo de aquí, corre por completo en tu navegador: los valores que pegues no se suben a ningún lado.