Generador de marcas de tiempo Unix

Cómo funciona

1. Convertir fecha a marca de tiempo: introduce una fecha y hora con el selector y haz clic en Generar para obtener la marca de tiempo Unix en segundos y milisegundos.
2. Convertir marca de tiempo a fecha: pega una marca de tiempo Unix (segundos o milisegundos) para convertirla de nuevo en fecha y hora legibles.
3. Obtener la marca de tiempo actual: haz clic en «Ahora» para obtener al instante la marca de tiempo Unix del momento presente.

¿Por qué usar el generador de marca de tiempo Unix?

Las marcas de tiempo Unix son el lenguaje universal del tiempo en informática: un único entero que representa los segundos transcurridos desde el 1 de enero de 1970 (UTC). Alimentan bases de datos, APIs, registros, tokens de autenticación y programación de eventos. Convertir manualmente entre marcas de tiempo y fechas legibles implica cálculos de zonas horarias fáciles de equivocar. Esta herramienta gestiona correctamente la conversión en ambos sentidos, ahorra tiempo y evita errores de zona horaria.

Funcionalidades

• Conversión bidireccional: fecha/hora → marca de tiempo Unix y marca de tiempo Unix → fecha/hora.
• Segundos y milisegundos: admite el tiempo Unix en segundos (10 cifras) y en milisegundos (13 cifras).
• Gestión de zonas horarias: muestra la hora en tu zona local y en UTC para una comparación sin ambigüedad.
• Botón hora actual: obtén al instante el timestamp del momento presente.
• Visualización relativa: indica cuánto tiempo hace o en cuánto tiempo (p. ej. «hace 3 días»).

Preguntas frecuentes

¿Qué es una marca de tiempo Unix?

Una marca de tiempo Unix es el número de segundos transcurridos desde la época Unix: medianoche UTC del 1 de enero de 1970. Es una representación de un instante independiente de las zonas horarias, lo que la convierte en el formato preferido para almacenar y comparar momentos en bases de datos y APIs.

¿Por qué JavaScript usa milisegundos?

Date.now() y new Date().getTime() en JavaScript devuelven milisegundos desde la época (un número de 13 dígitos), mientras que las herramientas Unix y la mayoría de las bases de datos usan segundos (10 dígitos). Comprueba si tu marca de tiempo tiene 10 o 13 dígitos para saber qué formato tienes.

¿Cómo convertir un timestamp a hora local?

Pega el timestamp; la herramienta lo convierte automáticamente a la zona local de tu navegador. La visualización muestra tanto la hora local como la UTC para trabajar entre zonas con confianza.

De dónde viene el tiempo Unix

El tiempo Unix fue definido por Ken Thompson y Dennis Ritchie en Unix First Edition (noviembre de 1971). Inicialmente el kernel contaba 60avos de segundo desde 1971-01-01 en un campo de 32 bits, que se desbordaba después de 2 años 9 meses. En Unix Sixth Edition (1975) el conteo se cambió a segundos desde 1970-01-01 00:00:00 UTC, la época que cada sistema tipo Unix todavía usa hoy. La elección fue arbitraria, los ingenieros necesitaban una fecha redonda cercana a la era en la que trabajaban. POSIX.1 (1988) codificó la definición como el estándar oficial, y POSIX.1-2017 (IEEE Std 1003.1-2017), la versión actual, todavía define time_t como el número de segundos desde la época, con la advertencia de que el tiempo POSIX finge que los segundos intercalares no existen. ISO 8601 (1988, actualmente 2019) estandarizó el formato legible 2026-05-13T14:30:00Z, y RFC 3339 (julio de 2002) lo restringió a un perfil de fecha-hora de internet inequívoco. Date.now() de JavaScript devuelve milisegundos desde la época porque la spec se escribió en 1995 cuando la precisión sub-segundo ya estaba en demanda; la mayoría de bases de datos y utilidades Unix todavía usan segundos enteros.

El problema del año 2038 (y por qué importa ahora)

Un time_t de 32 bits con signo puede representar como máximo 2.147.483.647 segundos, que llegan a las 03:14:07 UTC del martes 19 de enero de 2038. Un segundo después, el contador se envuelve a −2.147.483.648, que la mayoría del software interpreta como 13 de diciembre de 1901. Es la misma clase de bug que Y2K pero causada por el ancho entero, no el formato de fecha. La solución es usar time_t de 64 bits (que empuja el desbordamiento a aproximadamente el año 292 mil millones). La mayoría de sistemas Linux de 64 bits ya usan time_t de 64 bits por defecto; Linux 5.6 (marzo de 2020) hizo disponible time_t de 64 bits también en arquitecturas de 32 bits. El riesgo restante vive en sistemas embebidos, formatos de archivo binarios antiguos y protocolos de red de 32 bits. El protocolo NTP ya se envuelve en 2036 porque usa un contador sin signo de 32 bits desde 1900, NTPv4 agrega un número de era para extenderlo. Si entregas software que maneja fechas, audita tu stack antes de 2038, especialmente columnas SQL tipadas como INT(11) o código C antiguo con campos de tiempo long.

Los formatos de timestamp que encontrarás

• Segundos Unix (10 dígitos). 1747143000. El time_t POSIX clásico. Usado por PostgreSQL EXTRACT(epoch FROM ...), MySQL UNIX_TIMESTAMP(), TTLs Redis, reclamaciones iat/exp JWT (según RFC 7519), git log, y la mayoría de utilidades Unix. Tendrá 11 dígitos después de noviembre de 2286.
• Milisegundos Unix (13 dígitos). 1747143000000. Date.now() de JavaScript, System.currentTimeMillis() de Java, Kafka, Elasticsearch, y la mayoría de pipelines de logs modernos. Multiplicado por 1000 el conteo de segundos.
• Microsegundos Unix (16 dígitos) y nanosegundos (19 dígitos). 1747143000000000. Usado por time.time_ns() de Python, time.Now().UnixNano() de Go, revisiones MVCC etcd y sistemas de trading de alta frecuencia donde la resolución de milisegundos es demasiado gruesa.
• ISO 8601. 2026-05-13T14:30:00.000Z o 2026-05-13T14:30:00+02:00. Ordenable como cadena, inequívoco sobre la zona horaria, aceptado por prácticamente toda API moderna. El sufijo Z significa «hora Zulu», un designador OTAN para UTC.
• RFC 3339. Un perfil más estricto de ISO 8601 usado por JSON Schema, OpenAPI, y la mayoría de APIs REST. Requiere un designador de zona horaria y no permite algunas características ISO 8601 como fechas de semana y fechas ordinales.
• RFC 2822 / RFC 5322. Tue, 13 May 2026 14:30:00 +0000. El formato del encabezado de email Date:. Todavía omnipresente porque SMTP corre en todas partes.
• Fecha serial de Excel. Días fraccionarios desde 1900-01-01 (o 1904 en Excel Mac clásico). 2026-05-13 14:30 es aproximadamente 46150.6042. Excel trata famosamente 1900 como año bisiesto (no lo es) por compatibilidad con Lotus 1-2-3.

Cuando esta herramienta gana su sueldo

• Depuración JWT. El token tiene "exp": 1747143000 y necesitas saber si está expirado. Pega, ve la fecha humana.
• Forense de logs. Una línea dice timestamp=1747143012345, necesitas correlacionar con el tiempo de reloj de pared de otra herramienta. 13 dígitos, así que milisegundos.
• Consultas de base de datos. Quieres encontrar filas después de una fecha específica. WHERE created_at > 1747143000 necesita el valor en segundos; cópialo de la herramienta.
• Fixtures de pruebas. Codificar «ayer» en una prueba, generas el timestamp ahora y lo pegas en el spec.
• Cron / trabajos programados. Verifica el valor en segundos al que un planificador se disparará, especialmente a través de transiciones DST.
• Reproducción de eventos. Los offsets Kafka y los índices Elasticsearch a menudo usan timestamps ms; convierte a fecha para inspeccionar una ventana de reproducción específica.
• Invalidación de caché. Un encabezado Expires o If-Modified-Since en formato RFC 2822, genera el formato wire correcto para pruebas.

Errores que cuestan horas a los equipos

• Mezclar segundos y milisegundos. Pasar un valor de 10 dígitos a una función esperando milisegundos devuelve una fecha en 1970, desviada por un factor de 1000. La regla 10-vs-13 dígitos es la prueba más rápida, los valores modernos en segundos tienen 10 dígitos hasta 2286, en milisegundos 13 dígitos.
• Almacenar hora local. Siempre almacena en UTC; convierte a local en tiempo de visualización. Almacenar "2026-05-13 14:30:00" sin zona horaria se rompe en el momento en que un servidor, usuario o salto DST cambia el offset local.
• Olvidar las transiciones DST. Las 2:30 AM ocurren dos veces durante el retroceso. Código ingenuo que hace start + (24 * 3600) para significar «mañana» estará desviado por una hora dos veces al año. Usa una biblioteca de fechas real (luxon, date-fns-tz, Python zoneinfo) que conoce la base de datos IANA tz.
• Asumir que el tiempo POSIX cuenta los segundos intercalares. No lo hace. 2016-12-31 23:59:60 existió en la vida real (el 27º segundo intercalar) pero el time_t POSIX salta de 23:59:59 a 00:00:00 sin conciencia del segundo extra. TAI (Tiempo Atómico Internacional) sí cuenta los segundos intercalares, el tiempo POSIX está desplazado de UTC en cero segundos.
• Almacenar time_t en columnas INT(4). Los esquemas MySQL antiguos frecuentemente usan INT que es 4 bytes / 32 bits con signo / se envuelve en 2038. Migra a BIGINT o TIMESTAMP. El tipo TIMESTAMP de proveedores MySQL hospedados también es 4 bytes por defecto, revisa los docs.
• Parsear ISO 8601 con regex. Las implementaciones a medias descartan silenciosamente la zona horaria. Usa el parser de la plataforma: new Date(s) en JavaScript, datetime.fromisoformat(s) en Python ≥ 3.11, Instant.parse(s) en Java.
• Excel auto-convierte timestamps. Pegar 1747143012345 en Excel sin prefijarlo con ' (un apóstrofo literal) hace que Excel lo lea como número, a veces convirtiéndolo a notación científica. O bien formatea la columna como Texto primero, o pega con el prefijo apóstrofo.

Más preguntas frecuentes

¿Por qué se eligió 1970-01-01 como época?

Conveniencia. Las primeras versiones de Unix en los años 70 querían una época que no se desbordara dentro de una vida útil de trabajo razonable. 1970-01-01 era una fecha redonda cercana a la era de desarrollo, y un contador de segundos de 32 bits desde ahí llega cómodamente a 2038. La elección está ahora grabada en POSIX.1-2017 §4.16 y es uno de los acuerdos multiplataforma más estables en software. No hay significado inherente a la fecha, ningún evento histórico, ningún anclaje astronómico, solo un anclaje arbitrario que todos acordaron.

¿Cuál es la diferencia entre UTC, GMT y hora Zulu?

Para propósitos de software, se refieren al mismo tiempo de reloj de pared. UTC (Tiempo Universal Coordinado) es el estándar moderno, definido por relojes atómicos y el BIPM. GMT (Greenwich Mean Time) es el antiguo estándar astronómico británico que era la referencia mundial de facto antes del cronometraje atómico. Hora Zulu es el designador OTAN/militar para UTC, escrito como el sufijo Z en ISO 8601 (2026-05-13T14:30:00Z). UTC y GMT pueden diferir hasta 0,9 segundos porque UTC está dirigido a mantenerse cerca de UT1 (tiempo solar medio) vía segundos intercalares, pero ninguna aplicación que no use directamente UT1 lo notará.

¿Por qué a veces se muestra 1970 cuando esperaba algo más?

Dos causas comunes. Primero, el timestamp está en milisegundos pero se pasó a una función esperando segundos, o viceversa, dando una fecha desviada por un factor de 1000. Segundo, el valor es 0 o NaN, ambos los cuales la mayoría de bibliotecas de fechas renderizan como 1970-01-01T00:00:00Z. Inspecciona el ancho entero crudo: 10 dígitos son segundos, 13 son milisegundos, 16 son microsegundos, 19 son nanosegundos.

¿Esta herramienta manejará timestamps negativos para fechas antes de 1970?

Sí. new Date(-86400000) devuelve 1969-12-31T00:00:00Z. La Date de JavaScript puede representar cualquier momento desde −271821-04-20 hasta +275760-09-13, que es aproximadamente ±100 millones de días desde la época. Más allá de ese rango, la API devuelve Invalid Date. Para fechas históricas, también ten en cuenta la transición juliana-gregoriana (1582 en países católicos, 1752 en Gran Bretaña, hasta 1923 en Grecia) donde las fechas del calendario saltaron de 10 a 13 días; las bibliotecas de fechas varían en cómo manejan esto.

¿Mis datos de timestamp son enviados a alguna parte?

No. Toda conversión se ejecuta en JavaScript dentro de tu navegador. La página nunca envía valor alguno que ingreses. Abre la pestaña Red en DevTools y convierte un timestamp, verás cero solicitudes salientes durante la conversión. Seguro para tokens con reclamaciones de timestamp, líneas de log internas, o cualquier cosa que no pegarías en un servicio hospedado.