Why does Etc/GMT+5 put me in New York instead of the Maldives?
A server clock drifts five hours off. Meeting invites land at 3 AM. The culprit is a single plus sign in a zone name that means the opposite of what it says. Etc/GMT+5 is UTC−5. That is the offset New York uses on 15 January. Etc/GMT−5 is UTC+5, the offset for Pakistan. The IANA database is not broken. It follows a POSIX convention from the 1980s that deliberately swapped the sign. It has never changed. Changing it would silently corrupt timestamps on thousands of Unix systems.
Why POSIX made the Etc/GMT sign backwards
The POSIX standard described time zones with strings like EST+5. In that format the number is what you add to local time to reach UTC. New York in winter is 5 hours behind UTC. You add 5 to local time to get UTC. The string reads +5. Karachi is 5 hours ahead. You subtract 5. The string reads -5.
That is the reverse of the modern convention where UTC+5 means local time is 5 hours ahead. POSIX encoded the opposite.
When the IANA time zone database was created, it inherited this POSIX sign convention for the Etc/GMT zones. "Etc" stands for "etcetera." These were administrative placeholders for Unix systems that expected the POSIX format. They were never geographic zones. The database kept the old sign so legacy software would not break.
Which Etc/GMT zone matches which real offset?
On 15 January 2026, New York sits at UTC−5. The IANA zone for that offset is Etc/GMT+5. On 15 July 2026, New York moves to daylight time and becomes UTC−4. The matching Etc zone becomes Etc/GMT+4.
Dubai is always UTC+4. Its Etc zone is Etc/GMT−4.
The rule: take the UTC offset you want, flip the sign, append it to "Etc/GMT." UTC+3 becomes Etc/GMT−3. UTC−8 becomes Etc/GMT+8. UTC itself is Etc/UTC or Etc/GMT. Those two are safe. Zero has no sign to flip.
What two bugs do Etc zones cause in production?
First, the sign trap. Writing Etc/GMT+5 because "+5 means ahead" puts you on the wrong continent.
Second, the DST trap. Etc zones never observe daylight saving time. Use Etc/GMT+5 for New York and your timestamps are correct on 15 January but one hour off on 15 July. The geographic zone America/New_York handles the spring-forward and fall-back automatically. The Etc zone stays frozen.
Who should touch Etc zones (almost nobody)
The IANA documentation states the zones exist for compatibility only. The sign is inverted from standard convention.
One narrow case: a server that needs a fixed, never-changing offset and does not care about local daylight rules. A satellite ground station always referencing UTC−5 regardless of season might use Etc/GMT+5. A logging system that stores timestamps at a constant offset to avoid DST ambiguity might choose an Etc zone. Even then, storing UTC and converting at display time is safer.
Developers building applications for humans should avoid Etc zones outright. Meeting schedulers, flight booking systems, calendar apps, any code that asks "what time is it in London?" needs Europe/London, not Etc/GMT. London is UTC+0 in winter and UTC+1 in summer. Etc/GMT gives the winter offset all year.
Is Etc/UTC also reversed?
No. Etc/UTC has zero offset. The sign does not matter. It behaves exactly like UTC.
Why not just fix the sign in the IANA database?
Because it would break every system that already depends on the reversed convention. The IANA database values backward compatibility over consistency. Changing the sign would silently shift timestamps for thousands of Unix servers.
What is the difference between Etc/GMT and Etc/UTC?
Nothing meaningful. Both represent UTC+0 with no DST. Etc/GMT exists for historical compatibility with systems that expected "GMT" in the zone name. Use Etc/UTC if you need a fixed-zero zone.
Can I use Etc zones in modern programming languages?
You can. Most languages (Python, Java, Go) load them from the IANA database with the reversed sign. Passing Etc/GMT+5 to a library gives you UTC−5. The library is correct. Your expectation is wrong.
Which cities use Etc/GMT+5 as their actual local time?
In January, New York, Toronto, and Havana. In July, none. Those cities shift to daylight time. The Etc zone stays at UTC−5 year-round. It matches no populated city during summer.
What should a sysadmin do instead of using Etc zones?
Set the server's hardware clock to UTC. Store all timestamps in UTC. Convert to local time only when displaying to a user, using the geographic zone for the user's location. That avoids Etc zones entirely. It eliminates the sign confusion.