Is UTC the same as GMT?

Technically no. GMT is a time zone the UK uses in winter (UTC+0). UTC is a timescale that never changes. In practice they stay within a second of each other, but GMT can include daylight saving; UTC cannot.

Why does Etc/GMT+5 mean UTC-5?

The IANA database kept the POSIX convention where the sign is reversed. `Etc/GMT+5` means 5 hours west of Greenwich. Use named zones like `America/New_York` to avoid the confusion.

How do I avoid the midnight UTC date problem?

State the UTC date and time, then convert to the latest local time zone involved. A deadline of 00:00 UTC on 16 January is still 15 January in New York (UTC-5 in winter).

Can I use UTC as a time zone on my server?

Yes. The IANA zone `Etc/UTC` works as a time zone in most operating systems. It stays at UTC+0 year-round with no DST. This is the setting for servers and cloud services.

Common UTC Mistakes and How to Avoid Them

The most common UTC mistakes are assuming London is always UTC, misreading offset signs like Etc/GMT+5, and treating abbreviations like CST as unambiguous. Here is how to avoid them.

Why a midnight UTC deadline lands on two different dates

At 00:00 UTC on 15 January 2026, Mumbai is already starting the morning at 05:30. New York is still at 7:00 PM on 14 January, five hours behind. One moment, two calendar dates. This trips up more global deadlines than any other UTC mistake.

If your team spans Asia and the Americas, a cutoff set to midnight UTC silently steals a full working day from one side. Write the deadline in UTC, then convert it to the latest local time zone involved and state that explicitly: "00:00 UTC 15 January 2026 (7:00 PM 14 January in New York, UTC-5)." No one should have to do the maths in their head.

London is not UTC in July

London sits on the prime meridian. That single fact convinces people the city equals UTC year-round. It does not.

On 15 January 2026, London matches UTC. On 15 July 2026, British Summer Time pushes it to UTC+1. A meeting booked for "10:00 AM London time" in July happens at 09:00 UTC. Call it GMT in winter if you must, but check whether daylight saving is in force before you convert. For a fixed reference that never shifts, use UTC. More on the distinction at /utc-vs-gmt.

Why Etc/GMT+5 means UTC-5

Set a server to Etc/GMT+5 expecting Maldives time (UTC+5) and your clock lands 10 hours off. The IANA Etc/GMT series uses a legacy POSIX convention: the sign runs backwards. Plus means west of Greenwich. Minus means east.

Etc/UTC is safe. It always means UTC+0. For everything else, skip the Etc/GMT labels and use named zones: Asia/Dubai for UTC+4, America/New_York for UTC-5 in January. The full breakdown is at /utc-offset-explained.

Why hardcoding a UTC offset breaks when clocks change

UTC never shifts for daylight saving. Your local offset does.

On 15 January 2026, New York sits at UTC-5. On 15 July 2026, it moves to UTC-4. Los Angeles goes from UTC-8 to UTC-7. Paris from UTC+1 to UTC+2. Sydney from UTC+11 to UTC+10. Hardcode any of those January offsets and your conversions fail for half the year.

Store times in UTC. Convert to local time at display, using a current time zone database. Never store local time with a fixed offset.

Why three-letter codes like CST or BST break across borders

"CST" alone tells you nothing. It can mean China Standard Time (UTC+8), Central Standard Time in North America (UTC-6), or Cuba Standard Time (UTC-5).

"BST" is worse: British Summer Time (UTC+1), Bangladesh Standard Time (UTC+6), Bougainville Standard Time (UTC+11). "EST" points to Eastern Standard Time in the US (UTC-5) or Australian Eastern Standard Time (UTC+10).

In any message crossing a border, spell it out: "CST (China, UTC+8)" or "Central US, UTC-6." Better still, drop the abbreviation and write the offset. A full list of ambiguous codes is at /timezone-abbreviations.

UTC is a timescale, not a time zone

Calling UTC a time zone is like calling the metre a measuring tape. It is the reference. It has no DST, no territory, no local customs. Every civil time zone is UTC plus or minus some number of hours.

In practice, the IANA database provides Etc/UTC as a zone identifier so operating systems can treat it like one. Set your server to it, and you get a fixed UTC+0 offset forever. The distinction matters only when you are explaining the concept: UTC is the yardstick, not the thing measured.

How a leap second scrambles a Unix timestamp

Unix time counts seconds since 1970-01-01T00:00:00Z and pretends leap seconds do not exist. When a leap second fires (the last was 31 December 2016), the clock shows 23:59:60 UTC. The Unix timestamp does not advance. That extra second and the following 00:00:00 share the same integer.

Two events, one timestamp. Google and Amazon smear the extra second across hours to avoid the collision. High-frequency trading and scientific logging need to check how their stack handles the gap. The full story on leap seconds and the plan to drop them is at /leap-seconds-explained.

Quick checklist: avoiding UTC mistakes

Write "UTC," not "GMT," when you mean the fixed timescale.
For any deadline, state the UTC date and time, then convert to each participant's local time.
Use full IANA zone names (America/New_York) instead of the Etc/GMT series.
Never hardcode a UTC offset for a location that observes DST.
Treat any three-letter abbreviation as ambiguous until you see the offset.
Remember: Unix timestamps skip leap seconds.

The next major change to UTC is the planned end of leap seconds, set for no later than 2035 under CGPM Resolution 4. After that, the gap between UTC and astronomical time (UT1) will be allowed to grow beyond one second. Until then, UTC keeps the same steady beat it has held since 1972.