1704067200 es el 1 de enero de 2024 a las 00:00:00 UTC, la 1:00 en Madrid
Una marca de tiempo Unix (tiempo Unix, tiempo epoch) es el número de segundos transcurridos desde las 00:00:00 UTC del 1 de enero de 1970, que cuenta como 0. El número 1704067200 es el 1 de enero de 2024 a las 00:00:00 UTC. Madrid va una hora por delante de UTC en invierno, así que ese mismo instante son las 01:00 de esa misma fecha. El número de 13 cifras 1704067200000 es el mismo instante contado en milisegundos.
Si pegas un número en el conversor de arriba, el programa decide por el número de cifras si son segundos, milisegundos, microsegundos o nanosegundos y lo convierte en fecha. Si escribes una fecha y una hora, hace el camino inverso y te da el número. Al elegir una zona horaria aplica el horario de verano y las horas oficiales antiguas de ese lugar. La franja superior muestra el tiempo Unix actual, que cambia cada segundo, y la recta numérica de abajo indica si tu valor cabe en un entero de 32 bits.
Por qué se guarda la hora como un solo número y cuándo hay que convertirla
Una fecha escrita como "1 de enero de 2024, 01:00" solo señala un instante si además sabes en qué zona horaria está y si regía el horario de verano. Una marca de tiempo Unix es el mismo número en cualquier lugar de la Tierra en el mismo instante, y por eso la usan servidores, bases de datos y API para intercambiar horas. Si restas dos valores obtienes los segundos que hay entre ellos, y si los comparas sabes cuál ocurrió antes.
A cambio, nadie puede leer una fecha en un número suelto. Hace falta convertir en casos como estos:
- Al leer registros (logs): un error marcado solo como 1760000000 hay que pasarlo a hora local para compararlo con otros registros.
- Al revisar una respuesta de API o un token: las declaraciones exp, iat y nbf de un JSON Web Token (JWT) son valores NumericDate definidos en la RFC 7519, es decir, segundos desde 1970-01-01T00:00:00Z. Conviértelas para ver si el token ya ha caducado.
- Al consultar un intervalo en una base de datos: para buscar "todo el 1 de enero de 2024" en una columna numérica necesitas las marcas de la medianoche de inicio y de fin de ese día. La fila "Inicio y fin del día, el mes y el año" de arriba te las da.
- Al convertir una columna de una hoja de cálculo en fechas: si una columna exportada tiene números de 10 o 13 cifras, hay que elegir la unidad y la zona horaria y aplicar una fórmula (consulta la sección de Excel).
- Al introducir una fecha como número: las horas de envío programado o de caducidad de muchas herramientas se piden como marca de tiempo, así que una hora local concreta hay que convertirla antes.
Cómo se calcula: cada día dura exactamente 86.400 segundos
POSIX toma las 00:00:00 UTC del 1 de enero de 1970 como época (Epoch) y cuenta cada día desde entonces como exactamente 86.400 segundos. Pasar una fecha a número es, por tanto: los días desde la época hasta ese día, multiplicados por 86.400, más los segundos transcurridos desde la medianoche de ese día.
- Pasa la fecha y la hora a UTC: en Madrid en invierno hay que restar 1 hora. La 01:00 del 1 de enero de 2024 en Madrid son las 00:00 UTC de ese día.
- Cuenta los días desde el 1 de enero de 1970 hasta ese día: de 1970 a 2023 son 54 años × 365 días = 19.710 días, más un día por cada uno de los 13 años bisiestos (1972, 1976, …, 2020), lo que da 19.723 días.
- Multiplica los días por 86.400 y suma horas × 3.600 + minutos × 60 + segundos: 19.723 × 86.400 + 0 = 1.704.067.200 segundos.
- Ajusta la unidad: multiplica por 1.000 para milisegundos, por 1.000.000 para microsegundos y por 1.000.000.000 para nanosegundos.
tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400POSIX.1-2024 4.19 Seconds Since the Epoch (la fórmula para fechas posteriores a 1970, con división entera). La misma sección dice "each and every day shall be accounted for by exactly 86400 seconds" (cada día se cuenta como exactamente 86.400 segundos).
Para pasar de número a fecha se divide entre 86.400. 1.704.067.200 ÷ 86.400 = 19.723 con resto 0, así que son 19.723 días después del 1 de enero de 1970: el 1 de enero de 2024 a las 00:00:00 UTC. El conversor hace esta cuenta con enteros grandes hasta el nanosegundo y después suma el desfase real de la zona que elijas con los datos de zonas horarias IANA del navegador.
Cómo saber la unidad por el número de cifras: 10, 13, 16 y 19
Una marca de tiempo no dice en qué unidad está. Un mismo instante tiene 10 cifras en segundos y 13 en milisegundos. Para fechas actuales, el número de cifras y los criterios de detección automática del conversor son estos:
| Unidad | Valor | Cifras | Detección automática (parte entera) | Se usa sobre todo en |
|---|---|---|---|---|
| Segundos (s) | 1704067200 | 10 | Menos de 100.000 millones (1011) | PHP time(), MySQL UNIX_TIMESTAMP(), JWT, date +%s |
| Milisegundos (ms) | 1704067200000 | 13 | Desde 1011 hasta menos de 1014 | JavaScript Date.now(), Java System.currentTimeMillis() |
| Microsegundos (µs) | 1704067200000000 | 16 | Desde 1014 hasta menos de 1017 | Go UnixMicro() |
| Nanosegundos (ns) | 1704067200000000000 | 19 | 1017 o más | Python time.time_ns(), Go UnixNano() |
Con estos límites, cualquier instante entre el 3 de marzo de 1973 a las 09:46:40 UTC y el 16 de noviembre de 5138 a las 09:46:40 UTC se lee bien en la unidad en que esté escrito. Los números por debajo de un límite, como los milisegundos de 1970 a principios de marzo de 1973, se leen en la unidad inmediatamente menor. Si conoces la unidad de origen, elígela en "Unidad". Con un número de cifras poco habitual, como 11, 14 o 17, aparece un aviso para que lo compruebes.
Si se lee mal la unidad, la fecha se desvía mucho. 1704067200 leído como milisegundos da el 20 de enero de 1970 a las 17:21:07,200 UTC, y 1704067200000 leído como segundos cae hacia el año 55.970, fuera del rango de este conversor (año 9999). Si las fechas se amontonan en enero de 1970 o el conversor avisa de que el valor sale del rango 0001–9999, revisa primero la unidad.
Ejemplos de conversión
| Entrada | Unidad | UTC | Madrid |
|---|---|---|---|
| 0 | segundos | 1970-01-01 00:00:00 | 1970-01-01 01:00:00 |
| -1 | segundos | 1969-12-31 23:59:59 | 1970-01-01 00:59:59 |
| 1704063600 | segundos | 2023-12-31 23:00:00 | 2024-01-01 00:00:00 |
| 1704067200 | segundos | 2024-01-01 00:00:00 | 2024-01-01 01:00:00 (CET, UTC+1) |
| 1704067200.5 | segundos | 2024-01-01 00:00:00.500 | 2024-01-01 01:00:00.500 |
| 1704067200123 | milisegundos | 2024-01-01 00:00:00.123 | 2024-01-01 01:00:00.123 |
| 1704067200123456 | microsegundos | 2024-01-01 00:00:00.123456 | 2024-01-01 01:00:00.123456 |
| 1704067200123456789 | nanosegundos | 2024-01-01 00:00:00.123456789 | 2024-01-01 01:00:00.123456789 |
| 1782900000 | segundos | 2026-07-01 10:00:00 | 2026-07-01 12:00:00 (CEST, UTC+2) |
1704063600 es la medianoche del inicio de 2024 en Madrid. Has escrito una fecha de Madrid y, sin embargo, la columna UTC marca las 23:00 del día anterior, porque Madrid va una hora por delante de UTC en invierno. Las dos columnas señalan el mismo instante. En Canarias (Atlantic/Canary) la hora va una hora por detrás de la peninsular, así que 1704067200 es allí el 1 de enero de 2024 a las 00:00.
Números que conviene recordar
| Valor (segundos) | UTC | Madrid | Significado |
|---|---|---|---|
| 0 | 1970-01-01 00:00:00 | 1970-01-01 01:00:00 | La época (Epoch) |
| 1.000.000.000 | 2001-09-09 01:46:40 | 2001-09-09 03:46:40 (CEST) | Primera marca de 10 cifras (mil millones de segundos) |
| 1.234.567.890 | 2009-02-13 23:31:30 | 2009-02-14 00:31:30 | Las cifras del 1 al 0 en orden |
| 1.800.000.000 | 2027-01-15 08:00:00 | 2027-01-15 09:00:00 | 1800 millones de segundos (marca redonda de 100 millones) |
| 2.000.000.000 | 2033-05-18 03:33:20 | 2033-05-18 05:33:20 (CEST) | 2000 millones de segundos |
| 2.147.483.647 | 2038-01-19 03:14:07 | 2038-01-19 04:14:07 | Máximo de 32 bits con signo (231−1) |
| −2.147.483.648 | 1901-12-13 20:45:52 | 1901-12-13 20:45:52 (UTC+0) | Mínimo de 32 bits con signo (entonces España usaba la hora de Greenwich) |
| 4.294.967.295 | 2106-02-07 06:28:15 | 2106-02-07 07:28:15 | Máximo de 32 bits sin signo (232−1) |
Si se guardan nanosegundos en un entero de 64 bits con signo, el valor máximo, 9.223.372.036.854.775.807, es el 11 de abril de 2262 a las 23:47:16,854775807 UTC. La documentación de Go dice que el resultado de UnixNano() no está definido para fechas anteriores al año 1678 o posteriores a 2262.
El problema del año 2038: la hora en un entero de 32 bits
Si los segundos se guardan en un entero de 32 bits con signo, el valor máximo es 2.147.483.647, es decir, el 19 de enero de 2038 a las 03:14:07 UTC (las 04:14:07 en Madrid). El segundo siguiente no cabe. Si el número da la vuelta hasta el mínimo negativo, −2.147.483.648, la hora se lee como el 13 de diciembre de 1901 a las 20:45:52 UTC.
Un entero de 32 bits sin signo no admite negativos, pero llega hasta el 7 de febrero de 2106 a las 06:28:15 UTC. Un entero de 64 bits con signo que cuente segundos dura unos 292.000 millones de años, que a efectos prácticos es para siempre. Las dos bandas de la recta numérica de arriba representan estos dos rangos. Si el marcador queda fuera de una banda, ese valor no se puede guardar en ese formato.
Conviene comprobarlo en cualquier sitio que guarde 32 bits, como columnas de bases de datos, formatos de archivo y equipos antiguos, antes de introducir una fecha futura como un vencimiento en 2040. La documentación de MySQL 8.4 indica que UNIX_TIMESTAMP() acepta valores hasta 32536771199,999999 segundos en plataformas de 64 bits y hasta 2147483647,999999 en las de 32 bits.
La hora actual y su unidad en lenguajes y herramientas habituales
Si sabes qué programa generó una marca de tiempo, sabes su unidad. Las unidades de retorno de la tabla salen de la documentación oficial de cada proyecto.
| Entorno | Código | Unidad | Nota |
|---|---|---|---|
| JavaScript | Date.now() | milisegundos | Entero de 13 cifras |
| Python | time.time() · time.time_ns() | segundos · nanosegundos | time() es un número real con fracción |
| Java | System.currentTimeMillis() | milisegundos | La precisión depende del sistema operativo |
| PHP | time() | segundos | No incluye zona horaria |
| Go | time.Now().Unix() · UnixMilli() · UnixNano() | segundos · milisegundos · nanosegundos | UnixNano() solo cubre de 1678 a 2262 |
| MySQL | UNIX_TIMESTAMP() | segundos | Si se le da una fecha, la lee en la zona horaria de la sesión; la inversa es FROM_UNIXTIME() |
| PostgreSQL | EXTRACT(EPOCH FROM now()) | segundos | Incluye fracción de segundo; la inversa es to_timestamp() |
| Shell (GNU date) | date +%s | segundos | La inversa es date -u -d @1704067200 |
| JWT | exp · iat · nbf | segundos | NumericDate de la RFC 7519, se admiten fracciones |
Funciones como UNIX_TIMESTAMP('2024-01-01 00:00:00') de MySQL leen la fecha en la zona horaria de la conexión (sesión). La misma expresión puede dar valores distintos en servidores configurados con zonas diferentes, así que pega el resultado en este conversor para ver qué instante significaba.
Zonas horarias y horario de verano
Una marca de tiempo no contiene zona horaria. El mismo 1704067200 se ve como las 01:00 del 1 de enero de 2024 en Madrid, las 00:00 en Londres y en Canarias, y las 18:00 del 31 de diciembre de 2023 en Ciudad de México, pero es un único instante. La zona horaria solo importa cuando un número se muestra como una hora que una persona lee.
La hora de Madrid tampoco ha sido siempre UTC+1 en invierno y UTC+2 en verano. Los registros de la base de datos de zonas horarias IANA para Europe/Madrid son los siguientes, y el conversor usa el desfase vigente en la fecha que escribas.
| Periodo | Desfase estándar | Horario de verano |
|---|---|---|
| Antes del 1 de enero de 1901 | −0:14:44 | Ninguno (hora media local de Madrid) |
| Del 1 de enero de 1901 al 15 de marzo de 1940 | +0:00 | Hora de Europa Occidental; en algunos años se adelantó una hora en verano según las normas de España |
| Desde el 16 de marzo de 1940 | +1:00 | UTC+2 en verano; desde 1979 con las reglas de la UE (último domingo de marzo al último domingo de octubre) |
El horario de verano europeo lo fija la Directiva 2000/84/CE. Su artículo 2 dice que "el período de la hora de verano comenzará en todos los Estados miembros a la 1 de la madrugada, hora universal, del último domingo de marzo", y su artículo 3 que "terminará [...] a la 1 de la madrugada, hora universal, del último domingo de octubre". Por eso el mediodía del 1 de julio de 2026 en Madrid es 1782900000. Si usaras un +1 fijo para todas las fechas obtendrías 1782903600, una hora de diferencia.
El 29 de marzo de 2026 los relojes saltan de las 02:00 a las 03:00, así que de 02:00 a 02:59 no existe. El 25 de octubre de 2026 la franja de 02:00 a 02:59 ocurre dos veces. Si escribes una hora que no existe, como las 02:30 del 29 de marzo, el conversor la calcula como las 03:30 CEST. Si escribes una hora que ocurre dos veces, como las 02:30 del 25 de octubre, usa la primera, en horario de verano (1792888200, frente a 1792891800 para la segunda, en horario de invierno). Debajo del campo te avisa de qué caso se ha aplicado.
Los segundos intercalares no se cuentan
Para mantener los relojes al ritmo de la rotación de la Tierra, entre 1972 y 2016 se añadieron 27 segundos intercalares a UTC. El tiempo Unix cuenta cada día como exactamente 86.400 segundos, así que no existe ningún número para un segundo intercalar como las 23:59:60 UTC del 31 de diciembre de 2016. El valor siguiente a las 23:59:59 (1483228799) es 1483228800, que ya es el 1 de enero de 2017 a las 00:00:00 UTC.
Por eso, al restar dos marcas de tiempo que rodean un segundo intercalar, el resultado es un segundo menos que el tiempo realmente transcurrido. El Servicio Internacional de Rotación de la Tierra y Sistemas de Referencia (IERS) indicó en su Boletín C 72 de julio de 2026 que no se introducirá ningún segundo intercalar a finales de diciembre de 2026. UTC−TAI vale −37 segundos desde el 1 de enero de 2017. Si escribes 23:59:60 en el campo de hora, aparece un aviso de que ese segundo no existe en el tiempo Unix.
Convertir tiempo Unix en Excel
El sistema de fechas 1900 de Excel guarda una fecha como el número de días desde el 1 de enero de 1900. Para pasar segundos a fecha hay que dividir entre 86.400 y sumar el número de serie del 1 de enero de 1970, que es 25569. Con Excel en español, la función DATE se llama FECHA y los argumentos se separan con punto y coma; la página de ayuda de Microsoft da la sintaxis "FECHA(año; mes; día)". Con el valor en A1, las fórmulas son:
| Objetivo | Fórmula | Con A1 = 1704067200 |
|---|---|---|
| Segundos → fecha UTC | =A1/86400+FECHA(1970;1;1) | 45292 → 2024-01-01 00:00:00 |
| Segundos → hora de Madrid (invierno) | =A1/86400+FECHA(1970;1;1)+1/24 | 45292,0416667 → 2024-01-01 01:00:00 |
| Milisegundos → fecha UTC | =A1/86400000+FECHA(1970;1;1) | Con A1 = 1704067200000, 45292 |
| Fecha UTC → segundos | =(A1-FECHA(1970;1;1))*86400 | 2024-01-01 00:00 → 1704067200 |
| Hora de Madrid (invierno) → segundos | =(A1-FECHA(1970;1;1)-1/24)*86400 | 2024-01-01 01:00 → 1704067200 |
El resultado se muestra como un número normal, así que cambia el formato de la celda a fecha y hora, por ejemplo "aaaa-mm-dd hh:mm:ss". En verano usa 2/24 en lugar de 1/24. Un desfase fijo no puede seguir los cambios de horario de verano, así que comprueba con este conversor las fechas antiguas o cercanas a un cambio de hora. Si tu Excel está en inglés, la función se escribe DATE y los argumentos van separados por comas. Microsoft indica que Excel considera por error bisiesto el año 1900, de modo que los números de serie de fechas anteriores al 1 de marzo de 1900 difieren un día del calendario real. La fila "Valor de fecha de Excel / Hojas de cálculo" de arriba no muestra nada en ese periodo.
Errores frecuentes
- Escribir milisegundos como segundos: un número de 13 cifras en un campo de segundos cae decenas de miles de años en el futuro. Un número de 10 cifras leído como milisegundos cae en enero de 1970.
- Aplicar la zona horaria dos veces: el número no lleva zona, así que solo hay que sumar o restar horas una vez, al convertir el número en una hora de reloj. Si un registro ya imprime la hora local como texto, convertirla otra vez puede mover la fecha un día.
- Olvidar la zona en una fórmula de Excel: =A1/86400+FECHA(1970;1;1) da UTC. Para Madrid hay que sumar 1/24 (2/24 en verano), o los registros de la noche mostrarán un día equivocado.
- Poner fechas posteriores a 2038 en un campo de 32 bits: si el tipo de almacenamiento es un entero de 32 bits con signo, cualquier valor posterior a las 03:14:07 UTC del 19 de enero de 2038 se desborda.
- Tratar nanosegundos como números de JavaScript: Number no puede guardar con exactitud enteros mayores que 253 (9.007.199.254.740.992), así que 1704067200123456789 se convierte en 1704067200123456800. Guarda los nanosegundos como texto o como BigInt.
Límites
- Solo se convierten valores cuya fecha UTC y cuya fecha en la zona elegida estén entre el 1 de enero del año 0001 y el 31 de diciembre del año 9999, y no se aceptan cifras menores que un nanosegundo. Las fechas anteriores a 1582 se calculan extendiendo hacia atrás el calendario gregoriano actual.
- No se puede mostrar el segundo intercalar (23:59:60), porque el tiempo Unix no tiene un número para él.
- Las horas de cada zona salen de los datos de zonas horarias IANA incluidos en tu navegador. Un navegador con datos antiguos puede tardar en reflejar cambios de normas de un país que las haya modificado hace poco.
- "Ahora" y "Diferencia con ahora" siguen el reloj de este dispositivo, así que si el reloj va mal, los resultados también. La diferencia con ahora trata el año como de 365,2425 días, por lo que es aproximada.
- "Inicio y fin del día, el mes y el año" se mide desde la medianoche de la zona elegida. Donde un cambio de horario de verano se salta la medianoche, el inicio es la primera hora que existe ese día.
Fuentes
- 01The Open Group: POSIX.1-2024 Base Definitions, 4.19 Seconds Since the EpochFórmula de los segundos desde la época y "each and every day shall be accounted for by exactly 86400 seconds". La época se define en 3.125 (00:00:00 UTC del 1 de enero de 1970)
- 02IETF RFC 7519: JSON Web Token (JWT)Sección 2, NumericDate: segundos desde 1970-01-01T00:00:00Z, sin contar segundos intercalares, con fracciones permitidas. Secciones 4.1.4 a 4.1.6: exp, nbf e iat
- 03IETF RFC 3339: Date and Time on the Internet: TimestampsSección 5.6, formato date-time; los desfases llegan solo a ±hh:mm (un desfase con segundos no se puede escribir)
- 04IETF RFC 9110: HTTP Semantics, 5.6.7 Date/Time FormatsFormato de fecha HTTP preferido IMF-fixdate, por ejemplo "Sun, 06 Nov 1994 08:49:37 GMT"
- 05ECMAScript: Time Values and Time Range86.400.000 ms por día; rango de ±8.640.000.000.000.000 ms (±100 millones de días)
- 06MDN: Date.now()"returns the number of milliseconds elapsed since the epoch" (devuelve los milisegundos transcurridos desde la época)
- 07Documentación de Python: time.time() y time.time_ns()time() devuelve segundos desde la época como número real; time_ns() devuelve nanosegundos enteros. La mayoría de los sistemas Unix no cuentan los segundos intercalares
- 08Paquete time de Go: Time.Unix, UnixMilli, UnixMicro, UnixNanoEl resultado de UnixNano() no está definido para fechas anteriores a 1678 o posteriores a 2262
- 09MySQL 8.4: UNIX_TIMESTAMP() y FROM_UNIXTIME()Devuelve segundos; los argumentos de fecha se leen en la zona horaria de la sesión; límite en plataformas de 64 bits 32536771199,999999 segundos
- 10PostgreSQL: funciones de fecha y hora, EXTRACT(EPOCH) y to_timestampPara timestamp with time zone, la época son los segundos desde 1970-01-01 00:00:00 UTC (negativos antes de esa fecha)
- 11GNU coreutils: Seconds since the EpochEl número tras "@" son segundos desde la época; date +%s no cuenta los segundos intercalares
- 12Microsoft: Excel incorrectly assumes that the year 1900 is a leap yearEl error de año bisiesto del sistema de fechas 1900 y la diferencia de día de la semana antes del 1 de marzo de 1900. Los sistemas de fechas se explican en el soporte de Microsoft, "Date systems in Excel"
- 13IERS Boletín C 72 (6 de julio de 2026)"NO leap second will be introduced at the end of December 2026"; UTC−TAI = −37 s desde el 1 de enero de 2017
- 14Base de datos de zonas horarias IANA (tzdb) europeZone Europe/Madrid: -0:14:44 LMT hasta 1901 Jan 1 0:00u, 0:00 con reglas Spain hasta 1940 Mar 16 23:00, después 1:00 (reglas Spain hasta 1979, luego EU)
- 15Directiva 2000/84/CE del Parlamento Europeo y del Consejo, de 19 de enero de 2001, relativa a las disposiciones sobre la hora de veranoArtículos 2 y 3: la hora de verano empieza el último domingo de marzo y termina el último domingo de octubre, a la 1 de la madrugada, hora universal
- 16Microsoft Soporte: Función FECHASintaxis "FECHA(año; mes; día)" en Excel en español, con punto y coma como separador de argumentos
Fuentes comprobadas el 2026-10-18. Los datos de zonas horarias se revisan varias veces al año, y las horas en pantalla siguen la versión que lleva el navegador que uses.
Preguntas frecuentes
¿Cuál es la marca de tiempo Unix actual?
La franja "Tiempo Unix ahora" de arriba la muestra y se actualiza cada segundo con el reloj de este dispositivo. En octubre de 2026 es un número de 10 cifras de unos 1.790 millones, y en milisegundos tiene tres cifras más, 13 en total. "Copiar segundos" y "Copiar milisegundos" copian el valor del momento en que pulsas.
¿Qué fecha es 1704067200?
El 1 de enero de 2024 a las 00:00:00 UTC. En Madrid son las 01:00 de ese día, y en Ciudad de México las 18:00 del 31 de diciembre de 2023. El número de 13 cifras 1704067200000 es el mismo instante escrito en milisegundos.
¿Qué diferencia hay entre una marca de 10 cifras y una de 13?
En fechas actuales, 10 cifras son segundos y 13 cifras son milisegundos. El valor en milisegundos es 1.000 veces el valor en segundos del mismo instante. Con 16 cifras son microsegundos y con 19 nanosegundos. Si lees 10 cifras como milisegundos sale enero de 1970, y si lees 13 cifras como segundos sale una fecha a decenas de miles de años, así que si una fecha parece rara, revisa primero la unidad.
¿Cómo convierto una fecha local en una marca de tiempo?
Escribe la fecha y la hora y elige tu zona horaria, y los segundos aparecen en el campo del número. Por ejemplo, las 00:00:00 del 1 de enero de 2024 en Madrid son las 23:00 UTC del 31 de diciembre de 2023, es decir, 1704063600 segundos. Si dejas la zona en "Este dispositivo", se usa la zona de tu propio reloj.
¿Qué fórmula de Excel convierte tiempo Unix en fecha?
Con los segundos en A1, =A1/86400+FECHA(1970;1;1) da la fecha UTC en Excel en español. Para la hora de Madrid en invierno, suma +1/24 al final (+2/24 en verano). Con milisegundos, divide entre 86400000 en lugar de 86400. Da a la celda formato de fecha y hora, o solo verás un número.
¿Qué es el problema del año 2038?
Si los segundos se guardan en un entero de 32 bits con signo, el valor máximo es 2.147.483.647, que es el 19 de enero de 2038 a las 03:14:07 UTC (las 04:14:07 en Madrid). El segundo siguiente no cabe. Guardar el valor en un entero de 64 bits evita el problema.
¿Puede una marca de tiempo Unix ser negativa?
Sí. Cualquier instante anterior a las 00:00:00 UTC del 1 de enero de 1970 es negativo. -1 es el 31 de diciembre de 1969 a las 23:59:59 UTC, y el mínimo de 32 bits con signo, -2.147.483.648, es el 13 de diciembre de 1901 a las 20:45:52 UTC.
¿El tiempo Unix incluye los segundos intercalares?
No. POSIX cuenta cada día como exactamente 86.400 segundos. UTC ha tenido 27 segundos intercalares desde 1972, pero el tiempo Unix no tiene número para las 23:59:60, así que el valor siguiente a las 23:59:59 del 31 de diciembre de 2016 (1483228799) es 1483228800, que ya es el 1 de enero de 2017 a las 00:00:00.
¿Por qué cambia el resultado con el horario de verano?
Porque el desfase respecto a UTC es distinto en verano y en invierno. Madrid está en UTC+1 en invierno y en UTC+2 en verano, así que el mediodía del 1 de julio de 2026 es 1782900000, no el 1782903600 que saldría con un +1 fijo. El conversor usa el desfase vigente en la fecha que escribas.
¿También puedo convertir microsegundos y nanosegundos?
Sí. Con 16 cifras se lee en microsegundos y con 19 en nanosegundos, y ambos se calculan como enteros exactos. El Number normal de JavaScript no guarda con exactitud enteros mayores que 2^53, y las últimas cifras de un valor en nanosegundos cambiarían, pero este conversor usa aritmética BigInt.