Cómo convertir entre formatos horarios

Los formatos de tiempo varían entre sistemas, API y países. Marcas de tiempo Unix en respuestas de API, ISO 8601 en bases de datos, relojes de 12 horas en EE. UU., relojes de 24 horas en Europa: convertir entre ellos es una necesidad constante para desarrolladores y para cualquiera que trabaje con datos internacionales. Entender por qué existe cada formato, dónde brilla y dónde muerde convierte la conversión en un reflejo rápido en vez de una fuente recurrente de bugs sutiles.

Breve historia de los formatos de tiempo

Estandarizar el tiempo es más antiguo que internet. En 1884 la Conferencia Internacional del Meridiano estableció la hora media de Greenwich y el meridiano de origen, lo que dio al mundo una referencia común por primera vez. El reloj de 24 horas se extendió por la aviación y los militares por la misma razón: elimina la ambigüedad AM/PM que convierte una reserva de medianoche en un vuelo de mediodía.

El tiempo Unix llegó con el núcleo Unix original en 1971, contando segundos desde el 1 de enero de 1970 UTC (la "epoch"). La elección fue pragmática: un entero de 32 bits podía cubrir décadas, ordenar marcas de tiempo equivalía a ordenar números, y calcular intervalos era una resta. ISO 8601 llegó en 1988 para estandarizar el lado legible: año-mes-día en orden big-endian, T como separador fecha/hora y Z para UTC. RFC 3339 (2002) es un perfil más restrictivo de ISO 8601 diseñado para protocolos de internet. RFC 2822 (2001) define el formato estilo correo con nombres de día y offsets. Cada formato resuelve un problema real; ninguno reemplaza a los otros por completo.

Formatos de tiempo comunes

Seis formatos cubren casi todo lo que encontrarás en la práctica. La primera columna es el nombre que verás en la documentación; la columna de ejemplo muestra cómo se ve 14:30 del 7 de abril de 2024 UTC.

La mayoría de los equipos se asientan en milisegundos Unix para almacenamiento e ISO 8601 para tránsito, con formatos de visualización elegidos por locale. La elección importa menos que la consistencia: elige un formato principal, documéntalo y convierte en los bordes.

Referencia rápida de conversión

12 horas a 24 horas

El reloj de 12 horas tiene dos rarezas: las 12 AM son medianoche (el inicio del día) y las 12 PM son el mediodía. La tabla siguiente cubre los casos que confunden a la gente.

Marcas de tiempo a fechas

El conversor epoch traduce instantáneamente marcas de tiempo Unix a fechas legibles y viceversa. El conversor detecta automáticamente los formatos de segundos (10 dígitos) y milisegundos (13 dígitos), así que puedes pegar un valor desde cualquier fuente sin preocuparte por la unidad.

Una comprobación de cordura útil: divide por 86400 (segundos en un día) y luego suma 1970 días para ubicar mentalmente cualquier marca de tiempo. 1712502600 / 86400 ~ 19820 días, unos 54 años después de 1970, lo que lo sitúa en 2024. No es preciso pero basta para detectar errores de factor 1000 de un vistazo.

Ejemplos de conversión en código

La mayoría de los desarrolladores eventualmente necesita convertir marcas de tiempo en código. Las API principales son cortas:

• JavaScript, new Date(1712502600 * 1000).toISOString() devuelve 2024-04-07T14:30:00.000Z. Recuerda multiplicar por 1000 porque Date de JavaScript espera milisegundos. En sentido contrario: Math.floor(Date.now() / 1000) da una marca de tiempo en segundos.
• Python, datetime.fromtimestamp(1712502600, tz=timezone.utc).isoformat() devuelve 2024-04-07T14:30:00+00:00. Evita utcfromtimestamp(); devuelve un datetime ingenuo que el resto de tu código tratará erróneamente como hora local.
• Go, time.Unix(1712502600, 0).UTC().Format(time.RFC3339) devuelve 2024-04-07T14:30:00Z. El paquete time de Go es inusual pero consistente una vez interiorizado el diseño de referencia Mon Jan 2 15:04:05 MST 2006.
• Shell, date -u -d @1712502600 +"%Y-%m-%dT%H:%M:%SZ" en GNU/Linux, o date -u -r 1712502600 +"%Y-%m-%dT%H:%M:%SZ" en BSD/macOS. La diferencia de flag es uno de los traspiés multiplataforma más buscados en Google.
• Rust, chrono::DateTime::<chrono::Utc>::from_timestamp(1712502600, 0).unwrap().to_rfc3339() devuelve la misma cadena ISO. La biblioteca estándar ahora tiene SystemTime pero chrono sigue siendo la elección práctica para formatear.
• SQL (Postgres), SELECT to_timestamp(1712502600) AT TIME ZONE 'UTC'; devuelve un timestamptz. MySQL usa FROM_UNIXTIME(); SQLite usa datetime(1712502600, 'unixepoch').

Una herramienta de conversión es más rápida que cualquiera de estos one-liners cuando solo necesitas traducir un valor, que es la mayor parte del tiempo durante la depuración.

Por qué ISO 8601 gana para almacenamiento

ISO 8601 (y el perfil RFC 3339) se ordena correctamente como cadena pura. 2024-04-07T14:30:00Z va alfabéticamente antes de 2024-04-07T15:00:00Z, que va antes de 2024-04-08T00:00:00Z. Esa propiedad te deja ordenar marcas de tiempo sin parsearlas, agrupar líneas de log con sort | uniq -c y razonar sobre rangos con simples comparaciones de cadenas.

También es inequívoco de una forma que los formatos regionales no son. 04/07/2024 podría ser 7 de abril (EE. UU.) o 4 de julio (la mayor parte de Europa); 2024-04-07 es lo mismo en todas las locales. Para el intercambio máquina a máquina, esa falta de ambigüedad vale más que cualquier otra consideración de formato.

Errores comunes a evitar

• Olvidar el huso horario, 2026-04-07 14:30 es ambiguo sin huso. Incluye siempre Z o un offset +00:00 al almacenar cadenas ISO, y nunca confíes en el huso por defecto del lector.
• Mezclar segundos y milisegundos, una marca de tiempo Unix de 10 dígitos es segundos, una de 13 dígitos es milisegundos. Mezclarlas produce fechas en 1970 o muy en el futuro. Microsegundos (16 dígitos) y nanosegundos (19 dígitos) también se cuelan, así que anticípalos.
• Confiar en la hora local en servidores, si tu servidor está en UTC y tu usuario en Tokio, almacena UTC y convierte en pantalla. Dejar que el servidor infiera la locale lleva casi siempre a bugs cuando los usuarios viajan o cambia el horario de verano.
• Parsear con aritmética de cadenas, no cortes ni concatenes cadenas de fecha. Usa Date.parse(), dateutil.parser, chrono, o la biblioteca estándar de tu lenguaje. El parseo manual se rompe en fechas extremas, años bisiestos y offsets de huso.
• Confiar en new Date("2024-04-07"), JavaScript parsea cadenas solo-fecha como medianoche UTC, pero cadenas fecha-hora sin huso como medianoche local. El comportamiento difiere entre navegadores y versiones de Node. Incluye siempre un Z u offset explícito.
• Años de dos dígitos, 04/07/24 podría ser 1924, 2024 o 2124 según la implementación. Usa años de cuatro dígitos en todas partes.
• Transiciones de horario de verano, el reloj local salta una hora en primavera y repite una en otoño. Un planificador ingenuo puede ejecutar una tarea dos veces o ninguna esos días. Usa UTC para la lógica de planificación y convierte solo para mostrar.
• Segundos intercalares, el tiempo Unix finge que no existen suavizando o repitiendo el segundo afectado. El código que compara "segundos transcurridos" puede divergir brevemente de un reloj de pared que respete los segundos intercalares.
• El problema del año 2038, el time_t con signo de 32 bits desborda el 19 de enero de 2038. La mayoría de sistemas modernos usan tiempo de 64 bits, pero dispositivos embebidos heredados y columnas de base de datos antiguas aún pueden encontrarlo. Audita allí donde veas INT4 o int32 usado para almacenar marcas de tiempo.
• Formato dependiente de locale, toLocaleString() en JavaScript y funciones equivalentes en otros lenguajes producen salida diferente en máquinas diferentes. Para marcas de tiempo legibles por máquina, usa toISOString() o equivalente; para mostrar, formatea explícitamente.

Herramientas y bibliotecas alternativas

Un conversor maneja el caso puntual; para código de producción acudirás a una biblioteca.

La biblioteca correcta depende de tu stack; la disciplina correcta es la misma en todas partes: almacena UTC, transmite ISO 8601, formatea solo para mostrar y nunca confíes en una marca de tiempo sin huso explícito.

Privacidad y el conversor

El conversor de formatos de tiempo corre enteramente en tu navegador. Las marcas de tiempo que pegas y las fechas que generas nunca salen de la página. No hay registro en servidor de qué valores se convirtieron, ni analítica sobre qué formatos son populares, ni manera de que nadie ligue una solicitud a tu IP. Las conversiones de tiempo no son datos personales en sí, pero las marcas de tiempo en tus logs (horas de inicio de sesión, horas de transacción, ventanas de planificación) a menudo lo son, y pasarlas por un conversor de terceros podría filtrar detalles operativos. Hacer el trabajo del lado del cliente mantiene esa información en tu máquina donde pertenece. Para una tarea tan rutinaria como pasar entre segundos e ISO 8601, el ajuste de privacidad por defecto debería ser sin transmisión, sin registro, sin terceros en el bucle.