Understanding time zones and conversion
The world divides into 24 primary time zones, each roughly one hour apart, measured as offsets from UTC (Coordinated Universal Time). UTC itself is neither EST nor GMT — the distinction matters for precision. Greenwich Mean Time is based on Earth's rotation relative to the sun, while UTC is based on atomic clocks and is now the standard for all technical timekeeping. For practical purposes they're identical (within milliseconds), but UTC is what you'll see in programming, aviation, and science.
The real complexity lies in daylight saving time. The US observes it from the second Sunday in March to the first Sunday in November. Europe uses the last Sunday of March to the last Sunday of October. India doesn't observe DST at all and runs UTC+5:30 (a 30-minute offset, not 5 or 6 hours—unusual). Nepal is UTC+5:45. These half-hour and 45-minute offsets trip up anyone building global scheduling tools, and many countries have changed or abolished DST in recent years.
Why IANA time zone codes matter
- Use IANA identifiers, not abbreviations. “EST” means Eastern Standard Time, but what if it's summer? Use
America/New_Yorkinstead—the system automatically picks EST or EDT depending on the date. - Historical quirks are real. Some regions changed their UTC offset or DST rules years ago. Using
Asia/Kolkatainstead of “IST” ensures you're correct whether you're talking about 1950 or 2050. - Half-hour offsets exist. India, Nepal, Myanmar, parts of Australia, and a few others use 30 or 45-minute offsets. Most converters quietly ignore this, which is why your meeting time can be mysteriously off.
- The dateline is ragged. UTC+14 (Kiribati) is nearly a full day ahead of UTC-12 (Bakers Island). If you need to schedule across the Pacific, you'll see impossible overlaps that make global teams choose either 6 AM or midnight for some regions.
Practical scheduling tips
For teams spanning three or more zones, there is often no time that's reasonable for everyone. The standard workaround: rotate meeting times so the burden shifts each week. If you have London, New York, and Sydney, London-New York can meet in the afternoon (UTC 3–5 PM), but Sydney always loses. Rotate.
Always communicate deadline times in UTC to avoid ambiguity. “2 PM Friday” means nothing; “1900 UTC Friday” is unambiguous. Code review deadlines, API cutoffs, and release windows should always use UTC in writing.
Frequently asked questions
Why is my local time wrong after conversion?
Daylight saving time is the most common culprit. During the week clocks change, times shift. Check whether the date you're converting falls during a DST transition for either zone. If you're converting a date months in the future, that's another risk—DST rules have changed historically and may change again.
What's the difference between UTC, GMT, and Zulu time?
UTC is the international standard (atomic clock based). GMT is the older solar-based standard (functionally identical now). Zulu is military jargon for UTC. In practice, use UTC. It's unambiguous and it's what all machines use.
Do I need to worry about time zones for logs and databases?
Always store times in UTC in your database and logs. Convert to local time only for display. This eliminates DST chaos and makes reasoning about ordering and causality trivial—if Event A has a higher UTC timestamp than Event B, A definitely happened after B, no exceptions.
What about time zone abbreviations like CST?
They're ambiguous and fragile. CST could mean China Standard Time or Central Standard Time (North America). IST could be Indian Standard Time or Irish Standard Time. Always spell out the location or use UTC ± hours.
Can I convert a time far in the future?
Yes, but with a caveat. If you're converting a date 5+ years out, assume the DST rules in place now will still apply. Governments occasionally change DST dates or abolish it entirely, which will invalidate your conversion retroactively.