Konverter Zona Waktu

Zona waktu bukan sekadar offset dari UTC -- mereka adalah wilayah politik dan geografis yang kompleks dengan aturan mereka sendiri untuk waktu musim panas. Sebuah zona waktu mungkin memiliki offset UTC yang berbeda di musim panas vs musim dingin, dan aturan ini dapat berubah berdasarkan keputusan pemerintah. Database zona waktu IANA melacak semua aturan ini secara historis.

Historical timezone changes make things even harder. Countries frequently change their timezone rules -- Russia abolished DST in 2014, North Korea created its own timezone (UTC+8:30, later reverted to UTC+9) in 2015, and Chile has changed its DST rules multiple times. The IANA Time Zone Database (tzdata) tracks all these changes and is updated several times per year. Your browser uses this database via the Intl API, ensuring that historical timezone conversions are accurate. This is why you should never hard-code timezone offsets -- always use the IANA timezone name (e.g., 'America/New_York', not 'UTC-5').

A common mistake is confusing timezone offset with timezone. 'UTC-5' is an offset that changes twice a year for New York (UTC-5 during EST, UTC-4 during EDT). 'America/New_York' is a timezone that encapsulates the rules for when to switch. The Intl.DateTimeFormat API in modern browsers handles this correctly -- you specify the IANA timezone name and the API applies the correct offset for any given date and time.

Always store and transmit times in UTC. Convert to local time only for display. This eliminates ambiguity -- a UTC timestamp means the same thing everywhere in the world. When displaying times to users, use the Intl.DateTimeFormat API with the user's timezone (obtained from Intl.DateTimeFormat().resolvedOptions().timeZone) to show times in their local timezone automatically. For event scheduling, always include the timezone in the display (e.g., '3:00 PM EST' or '3:00 PM UTC-5') and consider using ISO 8601 format with timezone offset (e.g., 2024-01-15T15:00:00-05:00) for machine-readable data.

When scheduling meetings across timezones, use a tool that shows all participants' local times side by side. Be mindful of DST transitions -- a recurring meeting at '9 AM EST' doesn't exist during the DST gap in March. Also, some dates don't exist in all timezones: when the US springs forward, 2:00 AM to 3:00 AM doesn't exist, and when it falls back, 1:00 AM to 2:00 AM happens twice. These edge cases are handled automatically by the Intl API but can cause bugs if you're doing manual offset arithmetic.