Un companero de equipo me paso este numero: 1752345678, y me pregunto que fecha era. Le dije de un vistazo: alrededor del 2025-07-12. Unos segundos despues el volvio a preguntar — un momento, era el de 13 digitos 1752345678901 o el de 10 digitos 1752345678? Ese es el estado cotidiano de la mayoria de la gente con las marcas temporales UNIX: las reconoce a simple vista, no las sabe leer.

Esta guia existe para que la proxima vez que veas una cadena de 10, 13, 16 o 19 digitos, puedas decir al instante que dia, hora y segundo señala — y para entender por que la epoca resulta ser 1970-01-01.

Resumen en 30 segundos

  • 1970-01-01 00:00:00 UTC se eligio como epoca UNIX por tres motivos: el propio UNIX estaba naciendo en esa epoca; un entero con signo de 32 bits almacena el tiempo de forma mas comoda empezando desde ahi; y elegir un momento fijo en el pasado facilita alinear sistemas.
  • Una marca temporal UNIX es el numero de segundos desde ese momento (con decimales si hace falta precision sub-segundo). En la practica encontraras cuatro precisiones comunes: segundos, milisegundos, microsegundos y nanosegundos.
  • El propio recuento de digitos ya indica la precision: 10 digitos son segundos, 13 son milisegundos, 16 son microsegundos, 19 son nanosegundos. Solo con esa regla aciertas el 90% de las veces.
  • Para cambiar entre segundos, milisegundos, microsegundos, nanosegundos y fechas legibles cuando quieras, guarda en marcadores nuestro Convertidor de marca temporal UNIX.

5 escenarios reales: donde aparecen las marcas temporales

Escenario 1: un numero de 13 digitos en el log del servidor

Ves una linea tipo 1752345678901 INFO request completed en un log de backend. Ese numero es casi seguro milisegundos, no segundos.

Por que: los lenguajes de backend mas usados devuelven por defecto Date.now() (JavaScript), System.currentTimeMillis() (Java) o time.time() * 1000 (Python), todos milisegundos de 13 digitos.

Solucion: pega 1752345678901 en nuestro Convertidor de marca temporal UNIX. Detecta la precision automaticamente y muestra la hora UTC y la hora local. Sin la herramienta, recuerda que 13 digitos dividido entre 1000 dan unos 10 digitos, y 1752345678 corresponde aproximadamente al 2025-07-12.

Escenario 2: un numero de 10 digitos en una respuesta de API

Una API REST devuelve JSON como {"created_at": 1752345678, "expires_at": 1752346400}. Casi seguro son segundos.

Por que: algunas APIs antiguas (sobre todo de la era PHP y ciertas herramientas Unix) siguen usando segundos, y varias APIs publicas de tiempo los emiten directamente en segundos.

Solucion: mira el nombre del campo. Si se llama unix_timestamp o epoch_seconds, son segundos. Si se llama created_time_ms o timestamp_ms, son milisegundos. Nuestro Convertidor de marca temporal UNIX muestra las cuatro precisiones a la vez, asi que puedes verificar a ojo.

Escenario 3: los claims iat y exp en un JWT

El payload de un JWT suele contener iat: 1752345678 y exp: 1752349278. Ambos son segundos, no milisegundos.

Por que: el RFC 7519 (el estandar de JWT) define NumericDate como el numero de segundos desde la epoca (con decimales opcionales). Todas las librerias JWT conformes usan segundos.

Solucion: decodifica el token con nuestro Decodificador JWT. iat y exp se muestran en segundos por defecto. Si ves un iat de 13 digitos, es una senal de alarma — o la libreria metio milisegundos por error, o una implementacion no estandar esta en juego.

Escenario 4: ISO 8601 y epoch mezclados en la base de datos

Una trampa clasica: una columna guarda una cadena ISO 8601 (2025-07-12T10:30:00Z), otra guarda un entero epoch (1752345678). Los JOIN que olvidan unificar unidades se vuelven lentos, y las comparaciones que ignoran la zona horaria devuelven filas incorrectas.

Por que: es un residuo de una decada de scripts de migracion y ORMs. Distintos equipos y epocas de codigo dejan ambos formatos conviviendo en el mismo esquema.

Solucion: las tablas nuevas almacenan exactamente un unico formato de tiempo absoluto. Prefiere milisegundos epoch (13 digitos) o ISO 8601 con zona (2025-07-12T10:30:00+08:00). No mezcles.

Escenario 5: tres ingenieros en tres zonas horarias

Alguien publica en el chat una hora como 2025-07-12 10:30:00. Un companero la lee como hora de Pequin, otro como UTC, un tercero como hora del Pacifico de EE. UU. La reunion se retrasa ocho horas y alguien se conecta a medianoche.

Por que: una cadena de hora local sin zona horaria es una mina en la colaboracion entre zonas.

Solucion: en trabajo entre zonas usa solo ISO 8601 con zona (2025-07-12T10:30:00+08:00) o epoch (10 o 13 digitos). Ambos son absolutos y no dependen de donde este el lector. Como estandar de equipo, prefiere epoch ms — un numero, un formato, sin ambiguedad para quien lo pegue.

4 trampas habituales

Trampa 1: segundos contra milisegundos (la historia Y2K: 2000-01-01 = 946684800 segundos, no 946684800000)

La trampa clasica: el 2000-01-01, parte del codigo trato la epoca como milisegundos y calculo 946684800000. Al convertir eso de vuelta a fecha, desbordaba el entero con signo de 32 bits, bloqueando partes de algunos sistemas y mandando otras fechas a 1970.

Solucion: el recuento de digitos es tu primera pista. 10 digitos son segundos; 13 digitos son milisegundos. Si tu codigo mezcla unidades, define constantes como SECOND = 1 y MILLISECOND = 1000 y enruta todas las conversiones a traves de ellas. Nada de numeros sueltos.

Trampa 2: comparar dos epoch entre zonas es seguro; comparar dos cadenas locales naive no lo es

Dos epoch restados siempre dan una diferencia real en segundos, independiente de la zona. Dos cadenas locales naive como 2025-07-12 10:30:00 restadas dan una resta literal, no una diferencia real de tiempo, cuando los lectores estan en zonas distintas.

Solucion: persistencia y comparacion entre zonas usan solo epoch o ISO 8601 con zona. Las cadenas locales naive viven solo en la capa de UI — nunca para almacenamiento, nunca para comparacion.

Trampa 3: perdida de precision — los microsegundos de 16 digitos y los nanosegundos de 19 pierden precision en JavaScript

Number en JavaScript es doble precision IEEE 754. El techo de entero seguro es Number.MAX_SAFE_INTEGER = 2^53 - 1 ≈ 9.007 × 10^15. Un microsegundo de 16 digitos (hasta ~10^16) y un nanosegundo de 19 digitos (hasta ~10^19) superan ese rango, asi que guardarlos en un number de JS pierde precision.

Solucion: los lenguajes de backend como Go, Rust y los enteros de Python conservan la precision de forma nativa. El frontend puede mostrarlos, pero al volver a persistir en el servidor pasalos como cadenas ("1752345678901234567"). Las restas y comparaciones se hacen en el backend con bigint o una libreria de fechas.

Trampa 4: desbordamiento de 32 bits — despues del 2038-01-19 03:14:07 UTC, los enteros con signo de 32 bits dan la vuelta

Un entero con signo de 32 bits llega hasta 2^31 - 1 = 2147483647 segundos, que es justo el 2038-01-19 03:14:07 UTC. Mas alla, un time_t de 32 bits envuelve a negativo y la fecha del sistema salta a 1901. Eso es Y2K38.

Solucion: los lenguajes modernos (Go, Rust, Python 3, Node.js, Java) usan enteros de 64 bits o precision superior y no se ven afectados. Pero sistemas embebidos, mainframes COBOL legacy, ciertos dispositivos IoT y algunos drivers de base de datos siguen usando time_t de 32 bits. Audita esos caminos antes de 2038 o repetiran el drama Y2K a su manera.

Practicas recomendadas

  1. En tu codigo, usa cadenas ISO 8601 con zona para el tiempo absoluto — por ejemplo 2025-07-12T10:30:00+08:00. Los humanos lo leen, las maquinas lo parsean y no hay ambiguedad de zona.
  2. En transito y almacenamiento, usa milisegundos epoch (13 digitos) para el tiempo absoluto. Un numero, un formato, sin ambiguedad entre lenguajes. Funciona en payloads JSON, logs, columnas de base de datos y parametros de URL.
  3. Delante del usuario, convierte a cadenas de hora local. Usa Intl.DateTimeFormat o una libreria equivalente para localizar el tiempo absoluto — nunca hagas al usuario calcular zonas a mano.
  4. Al depurar y verificar, guarda en marcadores nuestro Convertidor de marca temporal UNIX. Pega un numero, ve UTC, hora local, ISO 8601, RFC 2822 y cuatro precisiones epoch en un segundo. Combinalo con nuestro Decodificador JWT para inspeccionar iat/exp y con nuestro Generador de expresiones cron para leer el epoch de los next-run — asi se cierra el ciclo de manejo del tiempo.
  5. Cuando las marcas temporales vengan codificadas en URL o en Base64 (estado OAuth, URLs firmadas, tokens con marca temporal), decodifica primero con nuestro Codificador de texto y luego pega el resultado en el Convertidor de marca temporal UNIX para ver la hora legible.

La dificultad con las marcas temporales no es la aritmetica — es mezclar precisiones y zonas. Cuando tu equipo se asienta en la pareja epoch ms + ISO 8601, el 90% de los incidentes por zonas dejan de ocurrir.

Hay que preocuparse aun por 2038?

Depende de donde mires.

Escritorios, servidores, moviles, funciones en la nube — time_t de 64 bits es el estandar, y Y2K38 no es un problema en esas plataformas. Linux, macOS, Windows, Go, Rust, Python 3, Node.js y Java son todos de 64 bits. El 2038-01-19 no pasara nada visible.

El riesgo real vive en sistemas embebidos, mainframes COBOL legacy, ciertos dispositivos IoT y algunos drivers de bases de datos o sistemas de archivos que siguen usando enteros con signo de 32 bits para time_t. Esos dispositivos llevan ciclos lentos de actualizacion de firmware — camaras de seguridad, routers, PLCs industriales, ECUs de automocion son las categorias de alto riesgo.

Solucion: si tu negocio depende de dispositivos o librerias de terceros, audita ahora tu cadena de dependencias. Busca time_t, int32_t guardando segundos, esquemas MySQL antiguos, codigo C embebido. Actualiza lo que puedas, escribe workarounds donde no puedas y reemplaza el resto antes de 2038.

Igual que en los anos previos al Y2K, el mundo de la ingenieria hara arreglos por lotes en una ventana. Y2K38 tiene su propia ventana — mas corta que la de Y2K porque los dispositivos de 32 bits estan ahora dispersos entre muchos fabricantes — y el trabajo empieza hoy.

Abre el Convertidor de marca temporal UNIX, pega un valor de milisegundos de 13 digitos y mira como la herramienta detecta la precision automaticamente y entrega las cuatro precisiones mas UTC, hora local, ISO 8601 y RFC 2822 de un golpe. Un clic en marcadores; una respuesta en un segundo. La proxima vez que alguien pegue 1752345678, tendras la respuesta.