El Salvador Runs on Central Time Year-Round
San Salvador sits in the Central Time Zone at UTC-6, and that's it. There's no daylight saving time shift, no seasonal clock changes, no complications from legislation. The country stopped observing DST in 1992, and since then it's been a flat UTC-6 every single day of the year. If you're scheduling anything involving San Salvador, you don't need to check whether DST is active. It never is. Here's the practical stuff. The zone designation is CST throughout the year, but calling it CST can be misleading because CST normally implies there's a CDT counterpart that swaps in during summer. El Salvador doesn't do that. I've seen people put "CST/CDT" on scheduling forms for Salvadoran contacts and then show up an hour early or late because they assumed a shift was coming. It isn't. The correct shorthand is just UTC-6 or CST with a note that DST is not observed. When it's noon in San Salvador, it's 1:00 PM in Mexico City (which may or may not be on DST depending on the border municipality), 2:00 PM in Bogotá, 3:00 PM in Quito, and 5:00 PM in New York during standard time. During US daylight saving, New York jumps to UTC-4, so San Salvador is only 1 hour behind New York in summer instead of the usual 2. That half-hour shift in the offset relative to the US East Coast trips people up constantly.
One edge case I ran into recently: a client in San Salvador was trying to sync a recurring meeting series to Google Calendar. The invite came through as "CST" and their calendar auto-adjusted it to CDT when I viewed it from a US account, shifting the meeting an hour earlier. The workaround was straightforward—I switched the invite timezone from "Central Time" to the specific "America/El_Salvador" IANA identifier, which locked it to UTC-6 with no DST rules attached. Once that was set, it stayed correct regardless of where anyone viewed it from. For developers and engineers working with timestamps, use the IANA timezone database entry America/El_Salvador. Avoid the older "CST6CDT" alias because that one carries US daylight saving rules and will produce incorrect offsets between March and November. Storing everything in UTC internally and converting to America/El_Salvador only at display time is the only reliable approach. I learned this the hard way when a batch job I wrote kept logging events at the wrong hour for three weeks because the server's timezone library had an outdated Olson database that still included a pre-1992 DST rule for El Salvador. If you need to download timezone data, the IANA timezone database at tzdata on releases.iana.org is the source. It's updated periodically, and while El Salvador's rule hasn't changed since 1992, keeping your system's tzdata current prevents other countries' changes from bleeding into your calculations. The last time this zone was modified in the database was to clean up historical entries, not to change the current offset.
Here's what most guides don't tell you: El Salvador's decision to abandon DST wasn't arbitrary. The country is near the equator, so seasonal daylight variation is minimal—roughly 12 hours of daylight year-round with maybe 30 minutes of variance. The economic rationale was straightforward. No meaningful energy savings from shifted daylight, but real costs from schedule disruptions in banking, logistics, and cross-border trade with the United States. Other Central American countries made the same calculation. Guatemala, Honduras, Nicaragua, and Costa Rica all stay on fixed offsets that are either UTC-6 or UTC-5 with no DST. Panama is UTC-5 year-round. The region is effectively locked into fixed time. The main pitfall people hit is assuming that because the US changes clocks, their Central American partners do too. They don't. Another pitfall is using offset-based timezone names like "UTC-6" in systems that treat them as floating offsets rather than proper zones. A floating UTC-6 doesn't carry the historical or future rule context, which matters if you're dealing with backdated records or if El Salvador ever does change its policy again—which is unlikely but not impossible. For everyday use, if you're booking a call with someone in San Salvador, convert their time to your local zone by adding or subtracting 6 hours from UTC. Check whether your own location is currently on daylight saving and adjust the difference accordingly. That's the only variable you need to track. The Salvadoran side never changes.
