Por qué nunca deberías usar abreviaciones de zona horaria como EST o PST en tu código

EST, PST, CST, IST — parecen zonas horarias. No lo son. Son abreviaciones informales que se mapean de forma inconsistente entre librerías, lenguajes y países. Usarlas en código es la manera más segura de introducir bugs de calendario que solo aparecen en producción dos veces al año, justo en el cambio de horario.

Por qué fallan las abreviaciones

Son ambiguas. IST por sí sola puede significar:

• India Standard Time (UTC+5:30)
• Ireland Standard Time (UTC+1)
• Israel Standard Time (UTC+2)

CST puede ser US Central Standard Time (UTC−6), China Standard Time (UTC+8), Cuba Standard Time (UTC−5) o Australian Central Standard Time (UTC+9:30).

Cuando tu librería de fechas se encuentra con CST, elige una. Cuál depende de la librería, su versión y a veces el locale del sistema. Puede que no te enteres de que eligió mal hasta que aparece un bug en producción — momento en el que el error lleva un tiempo ahí sin que nadie lo notara.

No codifican el horario de verano. EST es UTC−5, pero Nueva York en verano es EDT (UTC−4). Si parseas 2026-06-20 15:00 EST y lo tratas como UTC−5, te desvías una hora. Algunas librerías corrigen esto en silencio. Muchas no.

No tienen ningún estándar. A diferencia de los nombres IANA, las abreviaciones no tienen ninguna especificación que las rija. Distintos sistemas interpretan la misma cadena de formas diferentes.

Qué usar en su lugar

Los nombres de zona IANA son la manera correcta de identificar una zona horaria en código:

Los nombres IANA codifican todo el historial de cambios de horario. America/New_York sabe que Nueva York está en UTC−5 en invierno y UTC−4 en verano, y exactamente en qué fechas se producen esas transiciones.

En la práctica

JavaScript:

// Mal
new Date("2026-06-20 15:00 EST"); // ambiguo, depende de la librería

// Bien
const dt = new Temporal.ZonedDateTime(
  Temporal.PlainDateTime.from("2026-06-20T15:00"),
  "America/New_York",
);

Python:

# Mal
datetime.strptime('2026-06-20 15:00 EST', '%Y-%m-%d %H:%M %Z')  # poco fiable

# Bien
from zoneinfo import ZoneInfo
from datetime import datetime
dt = datetime(2026, 6, 20, 15, 0, tzinfo=ZoneInfo('America/New_York'))

PostgreSQL:

-- Mal: almacenar un timestamp sin zona
INSERT INTO events (start_time) VALUES ('2026-06-20 15:00:00');

-- Bien: guardar UTC y el nombre de zona en una columna aparte
INSERT INTO events (start_time_utc, user_timezone)
VALUES ('2026-06-20 19:00:00+00', 'America/New_York');

Cuando las abreviaciones vienen de fuera

No siempre puedes controlar lo que recibes. Si recibes una cadena de tiempo con una abreviación desde la entrada del usuario o una API externa, trátala como no fiable:

1. Obtén la zona IANA del usuario desde el navegador: Intl.DateTimeFormat().resolvedOptions().timeZone
2. Mapea las abreviaciones ambiguas a nombres IANA con una tabla de búsqueda — y marca las genuinamente ambiguas (como IST) en lugar de adivinar
3. Nunca des por sentado que la librería resolvió la abreviación correctamente

Impón nombres IANA en los puntos de entrada y te evitarás toda la categoría de bugs de calendario relacionados con el cambio de horario.