Trabajo con zonas horarias en Swift: del caos al orden

El tiempo es algo complicado: por qué los desarrolladores Swift se vuelven locos

¿Alguna vez ha enviado una notificación push que llegaba al usuario a las 3 de la madrugada? ¿O ha calculado una fecha límite para un equipo internacional y se ha desplazado un día entero? Bienvenido al mundo de las zonas horarias, esa área de la programación donde una «Z» omitida en una cadena puede destruir toda la lógica de una aplicación.

En Swift, trabajar con zonas horarias no es solo llamar a Date(). Es todo un ecosistema de clases: Date, TimeZone, DateFormatter, Calendar y DateComponents. Si no las comprende desde el principio, el proyecto se convertirá en una pesadilla de errores que solo se reproducen en usuarios de determinadas regiones.

En este artículo, desglosaremos el trabajo con zonas horarias en Swift: desde el formateo simple hasta escenarios complejos con el cambio al horario de verano. Aprenderá cómo no equivocarse con UTC, por qué Date es solo una marca de tiempo y cómo hacer que su aplicación funcione correctamente en cualquier rincón del mundo.

Date en Swift: la principal trampa para principiantes

Lo primero que debe recordar: Date en Swift no es una fecha ni una hora. Es simplemente la cantidad de segundos transcurridos desde el 1 de enero de 2001 a las 00:00:00 UTC (Fecha de Referencia). Date por sí mismo no sabe nada sobre husos horarios ni calendarios. Es una marca de tiempo absoluta.

Aquí está el error clásico de principiante:

let now = Date()\nprint(now) // "2025-03-15 14:30:00 +0000" — ¡esto es UTC, no su hora local!\n

Cuando imprime Date en la consola, Xcode lo muestra en UTC. Pero el usuario ve esta hora en su propia zona horaria. El problema es que muchos principiantes piensan que Date ya «conoce» su hora local. No. Date es solo un número. Y todo lo demás es interpretación.

Cómo obtener correctamente la hora actual en la zona deseada

Para trabajar con tiempo «humano», debe usar DateFormatter y TimeZone. Aquí hay un ejemplo mínimo funcional:

let dateFormatter = DateFormatter()\ndateFormatter.dateFormat = "yyyy-MM-dd HH:mm:ss"\ndateFormatter.timeZone = TimeZone(identifier: "Europe/Moscow")\n\nlet now = Date()\nlet moscowTime = dateFormatter.string(from: now)\nprint("Ahora en Moscú: \\(moscowTime)")\n

Recuerde la regla: almacene las fechas en UTC, muéstrelas en la zona local. Si guarda en la base de datos una cadena como «2025-03-15 14:30:00» sin especificar la zona horaria, está creando una bomba de tiempo. Siempre agregue el desplazamiento o use ISO 8601 con el sufijo «Z» o «+03:00».

TimeZone: su principal aliado y enemigo

La clase TimeZone en Swift es una interfaz para la base de datos de zonas horarias IANA (base de datos Olson). Contiene información sobre cambios de horario de verano, cambios históricos y zonas geográficas.

Las formas más populares de crear TimeZone:

\n
• Por identificador (recomendado): TimeZone(identifier: "America/New_York")
\n
• Por abreviatura (poco fiable): TimeZone(abbreviation: "EST") — puede confundir horario de verano/invierno
\n
• Por desplazamiento desde GMT: TimeZone(secondsFromGMT: 10800) — ignora el horario de verano
\n
• Zona del sistema actual: TimeZone.current
\n

Aquí hay un ejemplo de por qué las abreviaturas son malas:

let est = TimeZone(abbreviation: "EST") // Hora Estándar del Este (UTC-5)\nlet edt = TimeZone(abbreviation: "EDT") // Hora de Verano del Este (UTC-4)\n\n// ¡Pero si usa EST en julio, obtendrá la hora incorrecta!\n// Es mejor usar siempre "America/New_York" — él mismo tendrá en cuenta el horario de verano\n

Use siempre identificadores IANA: tienen en cuenta la historia y el cambio al horario de verano. Esto es críticamente importante para las aplicaciones,