Una marca de tiempo UNIX representa un instante como tiempo transcurrido desde la época UNIX. No guarda una zona horaria con nombre, una regla de horario de verano ni una etiqueta de calendario. Estas reglas se añaden cuando el instante se muestra para una persona o un lugar.
Respuesta rápida: Primero determina la unidad. Los valores contemporáneos de diez dígitos suelen usar segundos. Los valores contemporáneos de trece dígitos suelen usar milisegundos. Convierte el valor en un instante. Después, formatea ese instante en UTC o en una zona horaria IANA con nombre. Nunca trates un desplazamiento UTC fijo como una zona horaria completa.
Este caso de uso explica las unidades de época, los valores negativos, UTC, los desplazamientos, las transiciones estacionales, el texto ISO 8601, los límites de JavaScript y las conversiones de hora de archivo de Windows. Relaciona estos conceptos con el conversor de marcas de tiempo UNIX y la colección de herramientas de fecha, hora y marcas de tiempo.
¿Qué es una marca de tiempo UNIX?
La época UNIX comienza en 1970-01-01 00:00:00 UTC. Una marca de tiempo UNIX suele contar segundos sin saltos desde ese instante de referencia. Los valores positivos identifican instantes posteriores a la época. Los valores negativos identifican instantes anteriores cuando el sistema los admite.
El modelo temporal POSIX define los segundos desde la época mediante reglas de conversión de calendario. RFC 9636 define el tiempo UNIX como segundos enteros desde la época POSIX, sin segundos intercalares. Las implementaciones y los lenguajes pueden imponer intervalos más estrechos o distinta precisión numérica.
Una marca de tiempo no equivale a una fecha mostrada. Un instante puede aparecer como fechas locales diferentes en Tokio, Calcuta, Londres y Nueva York. La marca de tiempo no cambia. La presentación cambia porque cada lugar aplica sus reglas de zona horaria.
| Tipo de valor | Forma de ejemplo | Significado | Riesgo principal |
|---|---|---|---|
| Segundos UNIX | 1725148800 |
Segundos desde la época | Confundirlos con milisegundos |
| Milisegundos UNIX | 1725148800000 |
Milisegundos desde la época | Confundirlos con segundos |
Fecha y hora ISO con Z |
2024-09-01T00:00:00Z |
Instante UTC | Perder la Z al analizar |
| Fecha y hora ISO con desplazamiento | 2024-09-01T05:30:00+05:30 |
Instante y desplazamiento numérico | Tratar el desplazamiento como zona con nombre |
| Fecha y hora local | 2024-09-01 05:30 |
Campos de calendario sin instante único | Faltan zona y elección de solapamiento |
¿Una marca de tiempo UNIX depende de las zonas horarias?
No. Una marca de tiempo UNIX válida identifica un instante sin depender de la zona horaria de visualización. Las zonas horarias afectan la conversión entre ese instante y los campos del calendario local.
Respuesta directa: No sumes ni restes un desplazamiento UTC local para “convertir” la zona horaria de una marca UNIX. Conserva el instante. Pide a una biblioteca de zonas horarias que lo formatee con la zona de destino.
La aritmética manual con desplazamientos falla cuando un lugar cambia su desplazamiento. El horario de verano puede crear cambios estacionales. Los gobiernos pueden revisar las reglas civiles. Los desplazamientos históricos pueden diferir de los actuales. Algunas regiones usan desplazamientos que no son horas enteras.
La base de datos de zonas horarias IANA registra reglas civiles actuales e históricas para lugares representativos. Los sistemas actualizan esta base cuando cambian las reglas. America/New_York incluye un historial de reglas. -05:00 solo incluye un desplazamiento numérico.
¿Cómo detectas segundos frente a milisegundos?
Ninguna regla basada en dígitos funciona para todas las fechas. La magnitud ofrece una pista práctica para fechas actuales. No constituye un sistema formal de tipos. Una interfaz sólida debe pedir la unidad o indicar su inferencia.
Cerca de la época actual, los segundos UNIX suelen tener unos diez dígitos. Los milisegundos suelen tener unos trece. Los microsegundos y nanosegundos usan valores mayores. Las fechas futuras, las fechas negativas, los ceros iniciales, los decimales y las cadenas pueden invalidar una prueba de longitud.
Usa este proceso seguro:
- Lee la documentación del sistema de origen.
- Conserva el valor como texto hasta conocer su unidad e intervalo numérico.
- Selecciona segundos, milisegundos, microsegundos o nanosegundos de forma explícita.
- Usa una biblioteca capaz de manejar enteros cuando la precisión importe.
- Comprueba el año resultante contra el intervalo empresarial esperado.
- Muestra UTC y la zona horaria con nombre prevista.
Si 1725148800 produce una fecha de enero de 1970, el conversor probablemente trató segundos como milisegundos. Si 1725148800000 produce una fecha a miles de años, probablemente trató milisegundos como segundos. Un año razonable ayuda a validar. La documentación del origen sigue siendo la autoridad.
¿Por qué JavaScript puede perder precisión temporal?
JavaScript Number usa coma flotante binaria IEEE 754. Solo representa enteros con exactitud dentro de un intervalo seguro definido. Los milisegundos cercanos a fechas actuales caben con holgura. Los nanosegundos no caben.
ECMAScript Date guarda un valor temporal en milisegundos. La especificación de fechas ECMAScript define el valor y el intervalo admitido. Las implementaciones rechazan valores fuera del intervalo. El análisis también depende de la gramática de entrada y de la presencia de una zona.
Usa BigInt o una biblioteca adecuada para microsegundos o nanosegundos. No conviertas una cadena entera grande a Number antes de revisar su intervalo. La conversión puede redondear silenciosamente los dígitos inferiores y cambiar el instante.
Cuando una API devuelve marcas de tiempo, documenta la unidad en el nombre del campo o el esquema. createdAtEpochSeconds es más seguro que timestamp. JSON no distingue tamaños enteros más allá de su sintaxis numérica. El productor y el consumidor necesitan un contrato.
¿En qué se diferencian UTC, los desplazamientos y las zonas con nombre?
UTC es el estándar temporal común para instantes globales. Un desplazamiento UTC indica la diferencia entre la hora local y UTC en un instante. Una zona con nombre aporta reglas que determinan el desplazamiento según la fecha.
| Concepto | Ejemplo | Cambia según la fecha | Identifica un instante por sí solo |
|---|---|---|---|
| Marcador UTC | Z |
No | Sí, con fecha y hora |
| Desplazamiento numérico | +05:30 |
El valor no cambia | Sí, con fecha y hora |
| Zona IANA | Asia/Kolkata |
Puede cambiar | No, sin fecha y hora local |
| Hora local de pared | 2026-11-01 01:30 |
No corresponde | No |
Una zona con nombre puede asignar una hora local a dos instantes durante un retraso del reloj. También puede asignarla a ningún instante durante un adelanto. Las bibliotecas llaman a estas situaciones solapamientos y huecos. Una aplicación necesita una política de desambiguación.
Para programar eventos, guarda la semántica prevista. Una reunión única puede guardar un instante y una zona de visualización. Una cita recurrente a las 09:00 puede necesitar la hora local, la zona con nombre, la regla de repetición y el comportamiento ante cambios de la base de datos. Guardar solo el primer instante puede desplazar futuras citas.
¿Qué ocurre durante las transiciones del horario de verano?
Durante una transición de primavera, los relojes pueden adelantarse. Un intervalo local puede no existir. Durante una transición de otoño, pueden atrasarse. Un intervalo local puede ocurrir dos veces con desplazamientos diferentes.
Supón que un reloj local muestra 01:30 dos veces. Una cadena con solo fecha y hora local no identifica qué instante quiso el usuario. Añade el desplazamiento numérico o aplica una regla explícita anterior o posterior mediante una biblioteca con zona nombrada.
La propuesta ECMAScript Temporal modela estas diferencias. Su documentación de ZonedDateTime explica la hora exacta, la zona y el calendario. También expone el comportamiento de desambiguación para huecos y solapamientos. Comprueba el soporte y el estado de producción antes de depender de una interfaz propuesta.
No conserves desplazamientos de zona en caché indefinidamente. Actualiza el entorno o la base que aporta datos IANA. Mantén al día servidor, cliente, contenedor e imágenes de base de datos. Un conjunto obsoleto puede hacer que dos servicios calculen horas locales distintas para el mismo evento futuro.
¿Cómo debes formatear un instante?
Usa un formato legible por máquinas con un marcador UTC o desplazamiento explícito. RFC 3339 define un perfil de fecha y hora muy usado en Internet. La especificación RFC 3339 define fecha completa, hora completa, desplazamientos y segundos fraccionarios opcionales.
Ejemplos:
2026-09-01T12:00:00Zidentifica el mediodía UTC.2026-09-01T17:30:00+05:30identifica el mismo instante con desplazamiento.2026-09-01T12:00:00.123Zañade precisión de milisegundos.2026-09-01 12:00:00no declara una zona ni un desplazamiento.
Usa T y Z en mayúsculas cuando importe la interoperabilidad. Conserva la precisión fraccionaria necesaria. No añadas dígitos sin significado. Un origen con precisión de segundos no obtiene precisión de nanosegundos al añadir nueve ceros.
Para nuevos protocolos que deban llevar una zona con nombre, revisa el formato ampliado de RFC 9557. Añade anotaciones entre corchetes a las marcas RFC 3339, incluidos nombres de zona. Confirma el soporte de todos los consumidores antes de adoptarlo.
¿Cómo afectan los segundos intercalares al tiempo UNIX?
UTC incluye a veces segundos intercalares. Las representaciones UNIX y POSIX comunes no asignan una marca ordinaria única a cada etiqueta intercalar mediante una correspondencia continua simple. Los sistemas pueden ignorar, repetir, suavizar o tratar el evento con relojes especializados.
El proyecto IANA tz documenta decisiones y límites en su archivo teórico de la base de zonas. Las bibliotecas temporales suelen dirigirse a marcas civiles y no a mediciones científicas de alta precisión.
Si la aplicación trata secuencias financieras, datos de satélites, registros distribuidos o mediciones científicas, define la escala temporal. UTC, TAI, tiempo GPS, relojes monotónicos y relojes del sistema resuelven problemas distintos. Un conversor del navegador no debe ser la autoridad para tiempos de precisión.
Usa un reloj monotónico para medir duraciones dentro de un proceso. El reloj civil puede cambiar por sincronización, administración o máquinas virtuales. Guarda instantes de eventos para auditorías. Mide la duración del código con la interfaz monotónica de la plataforma.
¿Cómo conviertes una marca de tiempo UNIX con seguridad?
Sigue este flujo:
- Identifica el sistema de origen y la unidad.
- Conserva el valor original para auditoría y diagnóstico.
- Valida la sintaxis, el signo, el intervalo y la precisión permitida.
- Convierte el valor en un instante sin aplicar manualmente un desplazamiento local.
- Formatea el instante en UTC como referencia estable.
- Formatea el mismo instante en la zona IANA solicitada.
- Muestra el desplazamiento numérico usado en esa fecha.
- Compara el año y el contexto local con lo esperado.
El conversor de marcas de tiempo UNIX ofrece un flujo de conversión específico. Usa primero datos de ejemplo. Una herramienta del navegador ayuda a inspeccionar un valor. El contrato de la API de origen decide la unidad correcta.
Para conversiones masivas o de producción, usa una biblioteca mantenida. Fija y actualiza sus datos de zonas. Añade pruebas para huecos y solapamientos, cambios de año, valores negativos, fracciones y la entrada máxima permitida.
¿En qué se diferencian las horas de archivo de Windows?
La hora de archivo de Windows y el tiempo UNIX usan épocas y unidades distintas. Un valor FILETIME suele contar intervalos de 100 nanosegundos desde 1601-01-01 UTC. El tiempo UNIX suele contar segundos desde 1970-01-01 UTC.
La conversión necesita un desplazamiento de época y un factor de unidad. La aritmética de enteros grandes importa porque FILETIME puede superar el intervalo seguro de JavaScript. Una conversión mediante Number puede eliminar los últimos dígitos.
Usa la herramienta de UNIX a hora de archivo de Windows para una conversión controlada. Usa la herramienta de hora de archivo de Windows a UNIX para la dirección inversa. Conserva el entero original como texto. Verifica el resultado con otra implementación cuando importe la exactitud forense.
La documentación de Windows sobre horas de archivo describe los intervalos de 100 nanosegundos. Los sistemas de archivos pueden tener distinta resolución, actualización o conversión local. La unidad nominal no demuestra que el origen midió el tiempo con esa precisión.
Recomendaciones para bases de datos y API
Usa un tipo que corresponda al modelo. Una marca de base de datos con zona puede normalizar un instante, pero cada proveedor tiene su semántica. Una marca sin zona puede representar campos locales. Lee la documentación antes de diseñar migraciones.
Para eventos de API, envía una cadena RFC 3339 con Z o un entero documentado con unidad explícita. Evita valores sin documentar. Incluye por separado la zona con nombre cuando tenga significado empresarial.
Para citas futuras, guarda más que un instante cuando la hora local deba permanecer estable. Un registro útil puede incluir:
- fecha y hora local;
- identificador de zona IANA;
- regla de repetición;
- elección de desambiguación;
- entrada original del usuario;
- siguiente instante calculado;
- política de actualización de reglas.
Para registros de eventos pasados, guarda el instante y el contexto útil. El desplazamiento ayuda a mostrar y diagnosticar. La zona con nombre puede seguir importando para la interpretación humana.
Errores comunes con marcas de tiempo
Error 1: Adivinar la unidad solo por los dígitos
La cantidad de dígitos es una pista. No es un contrato. Confirma la unidad de origen y el intervalo esperado.
Error 2: Sumar un desplazamiento para cambiar la zona
Esta acción cambia el instante. Conserva el instante y formatéalo en la zona de destino.
Error 3: Usar una abreviatura como zona
Abreviaturas como CST pueden señalar varios lugares o desplazamientos. Usa un identificador IANA o un desplazamiento numérico documentado.
Error 4: Analizar una fecha y hora sin zona
Un analizador puede asumir la zona del dispositivo, UTC u otra regla. Exige un desplazamiento explícito para instantes. Trata la programación local mediante una zona con nombre.
Error 5: Ignorar huecos y solapamientos estacionales
Algunas horas locales no existen o aparecen dos veces. Añade casos de prueba y una política de desambiguación.
Error 6: Convertir marcas grandes mediante coma flotante
Los enteros de microsegundos, nanosegundos y FILETIME pueden perder precisión. Consérvalos como cadenas o enteros de precisión arbitraria.
Error 7: Confiar en el reloj del cliente para seguridad
Los relojes de dispositivos pueden ser incorrectos o manipulados. Los protocolos de seguridad necesitan validación del servidor, tolerancia de caducidad, protección contra repetición y una fuente temporal fiable.
Lista de validación
Antes de aceptar una conversión, responde estas preguntas:
| Comprobación | Motivo |
|---|---|
| ¿Cuál es la unidad de origen? | Un error de 1,000 veces crea una fecha incorrecta |
| ¿La entrada es un entero o decimal? | Las fracciones pueden cambiar la precisión |
| ¿El valor puede ser negativo? | Algunos sistemas rechazan fechas anteriores a la época |
| ¿El tipo numérico conserva el valor? | El redondeo puede cambiar unidades inferiores |
| ¿La salida usa UTC o una zona con nombre? | Las etiquetas locales necesitan reglas |
| ¿La hora local ocurre una vez? | El horario estacional crea huecos y solapamientos |
| ¿Qué versión de base de datos se aplica? | Las reglas civiles futuras pueden cambiar |
| ¿Qué precisión midió el origen? | Los dígitos guardados pueden exagerar la exactitud |
Esta lista convierte un número ambiguo en una conversión documentada. También mejora los informes de errores. Incluye el valor original, la unidad, el instante esperado, la zona de destino, el entorno y la versión de datos de zona.
Preguntas frecuentes
¿El tiempo UNIX siempre usa segundos?
La representación tradicional usa segundos. Muchas API usan milisegundos, microsegundos o nanosegundos y llaman al campo marca UNIX. Lee el esquema y la unidad.
¿El tiempo UNIX incluye una zona horaria?
No. Identifica un instante relativo a la época. Se aplica una zona con nombre al crear campos locales de calendario.
¿Qué zona horaria tiene 0?
La marca UNIX 0 corresponde a 1970-01-01 00:00:00 UTC en el modelo común. Las vistas locales pueden mostrar otra fecha u hora.
¿Por qué mi conversor muestra 1970?
La causa más habitual es una unidad incorrecta. Un valor en segundos tratado como milisegundos queda cerca de la época. Confirma la unidad.
¿Por qué dos conversores difieren una hora?
Pueden usar zonas, reglas estacionales, versiones de base de datos o políticas de ambigüedad distintas. Compara sus salidas UTC y sus zonas con nombre.
¿UTC equivale a GMT?
Suelen ser intercambiables para mostrar desplazamientos cotidianos. Tienen historias técnicas distintas. Usa UTC para protocolos y estándares explícitos.
¿Puedo guardar solo una marca UTC para reuniones recurrentes?
No cuando la reunión debe mantener una hora local. Guarda la zona con nombre y la semántica de repetición. Calcula futuros instantes con reglas actuales.
¿Debo usar ISO 8601 o tiempo UNIX?
Usa la representación adecuada para la interfaz. El texto RFC 3339 es legible y lleva un desplazamiento. Los enteros son compactos, pero necesitan una unidad documentada. Ambos pueden identificar el mismo instante.
Regla final de conversión
Una marca de tiempo UNIX identifica un instante. Una zona horaria explica cómo aparece ese instante en un reloj local. Mantén separados estos conceptos.
Confirma la unidad antes de convertir. Conserva la precisión entera. Muestra UTC como referencia estable. Aplica una zona IANA para la salida local. Prueba límites estacionales y fechas históricas. Estos pasos evitan la mayoría de los errores antes de que lleguen a datos de producción.