¿Cómo usar esta herramienta?
- Introducir un Unix Timestamp en segundos en el campo de entrada.
- El resultado en milisegundos aparece al instante — sin clic necesario.
- Copiar el resultado al portapapeles mediante el botón Copiar.
¿Qué hace el convertidor?
Un Unix Timestamp cuenta segundos desde el 1 de enero de 1970 00:00:00 UTC — la llamada Epoch. Los sistemas POSIX, C y Python usan segundos (10 dígitos). JavaScript, Java y Kafka usan milisegundos (13 dígitos). El convertidor convierte entre ambas representaciones: segundos × 1000 = milisegundos, milisegundos ÷ 1000 = segundos.
La conversión suena trivial pero es una de las fuentes de error más frecuentes en el intercambio de datos entre backend y frontend. Quien meta un timestamp de 10 dígitos en new Date() aterriza en enero de 1970 en vez del año actual.
¿Cuál es la fórmula de conversión?
La fórmula es exacta, sin redondeo:
Segundos (s) × 1000 = milisegundos (ms)
Milisegundos (ms) ÷ 1000 = segundos (s)
Ejemplo: el Unix Timestamp 1745230000 (segundos) corresponde a 1745230000000 (milisegundos). En JavaScript: new Date(1745230000000) da el 21 de abril de 2025, 12:26:40 UTC.
¿Qué ejemplos de uso hay?
Valores comunes y su conversión:
| Segundos (POSIX) | Milisegundos (JS) | Significado |
|---|---|---|
| 0 | 0 | Epoch: 1 ene. 1970 00:00:00 UTC |
| 86.400 | 86.400.000 | Exactamente un día (24 × 60 × 60) |
| 604.800 | 604.800.000 | Exactamente una semana |
| 2.629.746 | 2.629.746.000 | Mes promedio (30,44 días) |
| 31.556.952 | 31.556.952.000 | Año promedio (365,2425 días) |
| 1.745.230.000 | 1.745.230.000.000 | Abril 2025 (valor de referencia) |
| 2.147.483.647 | 2.147.483.647.000 | Límite Y2038 (máximo de 32 bits) |
Recuerde: un día tiene exactamente 86.400 segundos y una semana 604.800. Estos valores son constantes porque los Unix Timestamps no cuentan los segundos intercalares.
¿Qué áreas de uso hay?
Análisis de log y depuración: logs de servidor, eventos Kafka y entradas de base de datos guardan momentos como Unix Timestamps. Al comparar entre backend Python (segundos) y frontend JavaScript (milisegundos), el factor 1000 es decisivo. Sin conversión correcta, los dashboards muestran momentos en 1970 en vez del mes actual.
Desarrollo de API: las REST-APIs y webhooks transportan timestamps en distintas precisiones. Stripe usa segundos, Discord milisegundos, InfluxDB nanosegundos. Quien integre APIs necesita la conversión regularmente — no como cálculo mental sino como herramienta fiable.
Migración de datos: al importar datos CSV o JSON a una nueva base, la precisión del timestamp debe coincidir. PostgreSQL espera microsegundos, MongoDB milisegundos. Una conversión incorrecta lleva a series temporales rotas.
Evaluación Y2038: las empresas con sistemas heredados comprueban actualmente qué componentes siguen usando timestamps de 32 bits. El valor máximo 2.147.483.647 (19 de enero de 2038, 03:14:07 UTC) es el límite absoluto. Quien necesite almacenar timestamps más allá de ese valor requiere enteros de 64 bits.
Variantes de precisión de un vistazo
Además de segundos y milisegundos existen dos niveles más de precisión:
| Unidad | Dígitos | Ejemplo | Uso típico |
|---|---|---|---|
| Segundos (s) | 10 | 1745230000 | POSIX, C, Python, Unix |
| Milisegundos (ms) | 13 | 1745230000000 | JavaScript, Java, Kafka |
| Microsegundos (µs) | 16 | 1745230000000000 | PostgreSQL, Python time.time_ns() |
| Nanosegundos (ns) | 19 | 1745230000000000000 | Go, Rust, Temporal.Instant |
El número de dígitos es el medio de reconocimiento más fiable: 10 = segundos, 13 = milisegundos, 16 = microsegundos, 19 = nanosegundos.
El problema Y2038
El 19 de enero de 2038 a las 03:14:07 UTC, el valor 2147483647 alcanza el máximo de un entero con signo de 32 bits. Los sistemas que almacenan timestamps en 32 bits interpretan el siguiente valor como −2.147.483.648 — un salto atrás a 1901.
Los timestamps de 64 bits resuelven el problema: llegan hasta aproximadamente el año 292.000 millones. Todos los sistemas operativos modernos y lenguajes de programación usan 64 bits. Los más expuestos son los sistemas embebidos, los esquemas de bases de datos antiguos y el firmware no actualizado durante décadas.
La API Temporal (ES2026, Stage 4 desde marzo 2026) usa internamente nanosegundos como BigInt — el problema Y2038 no existe allí.
Preguntas frecuentes
Las respuestas a las preguntas más importantes están más arriba, en el bloque de FAQ — se publican como JSON-LD estructurado (FAQPage) para los buscadores.
¿Qué herramientas de tiempo están relacionadas?
Otras herramientas del ecosistema convertidor relacionadas con el tema:
- Formateador JSON — dar formato legible a respuestas API con timestamps y detectar errores de sintaxis.
- Contador de caracteres — comprobar el número de dígitos de un timestamp para distinguir segundos de milisegundos.
- Diferencia de texto — comparar dos archivos de log con timestamps y resaltar las diferencias.
Última actualización: