Horário de verão para programadores

Why DST Is a Programming Nightmare

Daylight saving time is considered one of the most error-prone areas of software development. The reasons are numerous: DST rules change frequently, different countries transition on different dates, the transitions create ambiguous and non-existent times, and edge cases abound. The infamous programmer saying goes: "Time zones are a lie."

The Fundamental Rule: Store UTC, Display Local

The single most important principle for handling time in software is:

• Store all timestamps in UTC. UTC never has DST. It never changes. It is unambiguous.
• Convert to local time only for display. Use the user's time zone and the current DST rules to convert UTC to local time at rendering time.

Ambiguous and Non-Existent Times

Two special cases arise during DST transitions:

• Non-existent times (spring forward): When clocks spring forward from 2:00 AM to 3:00 AM, the times 2:00–2:59 AM do not exist. Any code that assumes every local time is valid will fail here.
• Ambiguous times (fall back): When clocks fall back from 2:00 AM to 1:00 AM, the times 1:00–1:59 AM occur twice. A timestamp of "1:30 AM" on that day is ambiguous without knowing whether it's the first or second occurrence.

Use IANA Timezone Database

Never hardcode UTC offsets like "UTC+5" or "EST" into your application. Instead, use IANA timezone identifiers like America/New_York or Europe/London. These identifiers reference the comprehensive IANA timezone database (also called the Olson database), which includes historical and current DST rules for all regions. Most programming languages have libraries that use this database:

• Python: zoneinfo (stdlib, Python 3.9+) or pytz
• JavaScript: Intl.DateTimeFormat (native) or date-fns-tz
• Java: java.time.ZoneId
• Go: time.LoadLocation

Keep Timezone Data Updated

DST rules change regularly — sometimes with only weeks of notice. Countries update their rules, shift their transition dates, or abolish DST entirely. Ensure your timezone database is updated with your OS and library updates. Server environments are especially vulnerable if OS timezone packages are outdated.

Common Pitfalls

• Scheduling a recurring event at "2:00 AM daily" — this time may not exist during spring forward.
• Calculating time differences across DST boundaries using simple arithmetic instead of a proper datetime library.
• Displaying user-entered local times without round-tripping through UTC.
• Assuming all days have 24 hours — DST days have 23 or 25 hours.
• Relying on system clock for timezone information in containerized or multi-region deployments.