Initializing, please wait a moment

Timestamps Unix explicados - epoch, ISO-8601 y zonas horarias

Cada log de servidor, fila de base de datos y respuesta de API en internet codifica "cuando paso algo" en uno de cuatro formatos: el epoch Unix (segundos o milisegundos), ISO 8601 o RFC 2822. Si alguna vez has pegado un timestamp en Slack solo para discutir en que zona horaria estaba, esta guia es para ti. Cubre que codifica realmente cada formato, como convertir entre ellos y las tres trampas que pillan incluso a desarrolladores experimentados.


Epoch Unix: segundos desde 1970-01-01 UTC

El timestamp Unix - tambien llamado "tiempo epoch" - es el numero de segundos que han transcurrido desde 00:00:00 UTC del 1 de enero de 1970. Ese punto de referencia es arbitrario pero universal; cada sistema derivado de Unix (Linux, macOS, Android, iOS) y casi todos los lenguajes de programacion rastrean el tiempo internamente como una cuenta desde ese momento.

Un valor actualizado: 1776495426 se traduce a 2026-04-18 12:17:06 UTC. No hay zona horaria codificada en el numero en si - es siempre UTC - lo cual es a la vez una fortaleza (sin ambiguedad cuando dos sistemas comparan timestamps) y una trampa (lo que sea que convierta el numero a una cadena legible tiene que elegir una zona horaria, y normalmente elige la local).


Segundos vs milisegundos: la primera fuente de confusion

JavaScript, Java y la mayoria de las bibliotecas estandar de lenguajes modernos usan por defecto milisegundos desde el epoch, no segundos. Ese mismo momento - 2026-04-18 12:17:06 UTC - es 1776495426 en segundos (10 digitos) pero 1776495426000 en milisegundos (13 digitos). Una regla rapida para comprobar la cordura de un timestamp que has recibido:

  • 10 digitos → segundos (linea de comandos Unix, PHP, Python time.time(), Go).
  • 13 digitos → milisegundos (JavaScript Date.now(), Java System.currentTimeMillis(), la mayoria de las API JSON).
  • 16 o 19 digitos → microsegundos o nanosegundos (telemetria especializada y temporizacion cientifica).

Un valor de 10 digitos en segundos interpretado como milisegundos se renderiza como una fecha de 1970 (50+ anos demasiado temprano). Un valor de 13 digitos en milisegundos interpretado como segundos se renderiza como una fecha ~56,000 DC. Ambos errores son instantaneamente visibles una vez convertido el timestamp - usa Convert Milliseconds to Date para una comprobacion de cordura, o Get Current Time in Milliseconds para comparar con el ahora.


ISO 8601: el formato de intercambio legible

ISO 8601 es un formato de fecha-hora legible para humanos en el que las maquinas tambien estan de acuerdo. La forma canonica se ve asi: 2026-04-18T12:17:06.520Z. Partes:

  • Fecha: 2026-04-18 (AAAA-MM-DD, siempre en este orden).
  • Separador: T (letra T literal entre fecha y hora).
  • Hora: 12:17:06.520 (HH:MM:SS.sss, 24 horas).
  • Zona horaria: Z para UTC, o un offset como +07:00 / -05:30 para otras zonas.

ISO 8601 no es ambiguo (sin confusion regional de fechas como 04-18 vs 18-04), ordenable como cadena simple (el orden lexical coincide con el orden cronologico cuando la zona horaria es la misma), y soportado por todos los parsers modernos. Si controlas la API que estas construyendo, prefiere cadenas ISO 8601 sobre numeros raw de epoch Unix - llevan la zona horaria explicitamente, lo cual elimina toda una clase de bugs.


RFC 2822: el formato legado de email y HTTP

RFC 2822 (y el HTTP-date casi identico del RFC 7231) se ve asi: Sat, 18 Apr 2026 12:17:06 +0000. Es el formato que veras en cabeceras Date: de email, cabeceras HTTP Last-Modified, y algunas API web mas antiguas. Es legible pero no ordenable como cadena simple (el prefijo del dia de la semana rompe la ordenacion lexical), por lo que los sistemas devuelven cada vez mas ISO 8601 junto con o en lugar de RFC 2822. Cuando necesitas generar RFC 2822 manualmente, usa una biblioteca en lugar de construir la cadena tu mismo - el nombre del dia de la semana y la abreviatura del mes son sensibles a la configuracion regional y faciles de equivocar.


UTC vs hora local: la raiz de la mayoria de los bugs de timestamp

Los timestamps de epoch Unix son siempre UTC; las cadenas ISO 8601 pueden ser UTC (Z) o cualquier offset; RFC 2822 casi siempre lleva un offset. Pero cuando un programa muestra un timestamp, normalmente convierte a la zona horaria local de la maquina que esta mostrando.

Esto esta bien para un solo usuario pero causa caos en tres escenarios:

  • Compartir un timestamp en el chat. "El deploy paso a las 14:00" es ambiguo - 14:00 de quien? Pega el valor ISO 8601 (2026-04-18T14:00:00+07:00) o indica explicitamente la zona horaria.
  • Logs de varios servidores. Configura cada servidor en UTC. Siempre. Los agregadores de logs y las herramientas de respuesta a incidentes asumen UTC; mezclar zonas horarias en logs es la forma mas rapida de atribuir mal una cadena causa-efecto.
  • Horarios orientados al usuario. Almacena la hora del evento en UTC (o la zona horaria fuente del evento con offset explicito) y convierte en el momento de la visualizacion. No almacenes "7pm" sin zona horaria; "7pm" en la sesion de un usuario puede ser 4pm para otro.

Tres trampas comunes (y como pillarlas)

1. Timestamps enteros vs cadenas en JSON. El JSON.parse de JavaScript producira fielmente un numero para 1776495426520 - pero si la API devolvio el mismo timestamp como cadena "1776495426520", cualquier codigo aguas abajo que haga aritmetica con el la coercera silenciosamente. Comprueba siempre el tipo antes de pasarlo a new Date().

2. Mes 0-11 en JavaScript Date. new Date(2026, 3, 18) es 18 de abril de 2026, no 18 de marzo de 2026. El mes esta indexado en 0 pero el dia y el ano estan indexados en 1. Prefiere el constructor ISO 8601 (new Date("2026-04-18")) que sigue la numeracion natural.

3. Transiciones de horario de verano. En la noche de "adelantar la hora", las 2:30 de la manana en hora local no existen; en la noche de "retrasar la hora", las 1:30 de la manana ocurren dos veces. Si tu sistema almacena cadenas de hora local, esos momentos crean timestamps imposibles o duplicados. El almacenamiento UTC elimina el problema; bibliotecas de Date como Luxon o date-fns-tz manejan la conversion explicitamente.


Herramientas relacionadas


← Volver a Utility Tools

Reviewed by the Free Tool Online editorial team · Tested in the current versions of Chrome, Firefox, Safari, and Edge before publishing. Your file is processed in your browser and never uploaded. Report a bug - we triage within 72 hours. · Last refreshed April 2026.

Why trust these tools

  • Ten-plus years of web tooling. The freetoolonline editorial team has shipped browser-based utilities since 2015. The goal has never changed: get you to a working output fast, without an install.
  • Truly in-browser - no upload. Every file-processing tool on this site runs in your browser through modern Web APIs (File, FileReader, Canvas, Web Audio, WebGL, Web Workers). Your photo, PDF, audio, or text never leaves your device.
  • No tracking during tool use. Analytics ends at the page view. The actual input you paste, drop, or capture is never sent to any server and never written to any log.
  • Open-source core components. The processing engines underneath (libheif, libde265, pdf-lib, terser, clean-css, ffmpeg.wasm, and others) are public and audit-able. We link to each one in its tool page's footer.
  • Free, with or without ads. All tools are fully functional without sign-up. The Disable Ads button in the header is always available if you need a distraction-free run.