UTC

UTC (Coordinated Universal Time) is the global reference time standard. Every other time zone in common use is defined as an offset from UTC — usually a whole number of hours, occasionally a half or quarter hour (India is UTC+5:30; Nepal is UTC+5:45). UTC itself does not observe daylight saving.

UTC is maintained by the International Bureau of Weights and Measures (BIPM) and the International Earth Rotation and Reference Systems Service (IERS). Its tick rate comes from a weighted average of atomic clocks in 80+ laboratories worldwide. Occasional leap seconds have been inserted (or, hypothetically, removed) to keep UTC within 0.9 seconds of solar time. As of 2026 leap seconds are scheduled for deprecation in 2035.

UTC is often confused with GMT(Greenwich Mean Time). For most practical purposes they’re identical — both represent the time at the Greenwich meridian without DST. The technical difference is that GMT is defined by Earth’s rotation (which is irregular) and UTC by atomic clocks (which are regular). When the UK is on summer time it observes BST (British Summer Time = UTC+1); GMT is then unused as a clock label even though the timezone name persists.

Convert between UTC and any of 28 major time zones with our timezone converter, which uses the browser’s IANA timezone database for DST-correct results.

Why “UTC” instead of CUT or TUC:the acronym is a deliberate compromise. English-speakers wanted “CUT” (Coordinated Universal Time); French-speakers wanted “TUC” (Temps Universel Coordonné). The ITU and BIPM settled on UTC in 1970 as a language-neutral ordering that matches neither expansion exactly. The convention is to write the abbreviation in upper case regardless of which spelling-out is used in surrounding text.

UTC in code — what to actually store:the operational rule for any system handling multi-timezone data is “store in UTC, render in local”. Database timestamps belong in UTC (PostgreSQL TIMESTAMP WITH TIME ZONEnormalises to UTC internally; MySQL TIMESTAMPdoes the same; MongoDB Dateis UTC by spec). Display layers convert to the user’s locale at render time. Storing wall-clock local times without zone information is the canonical source of “the booking moved by an hour after DST” bugs and is universally considered an anti-pattern. Reference: BIPM — Coordinated Universal Time (UTC).

Worked example

A user in New York schedules a meeting for “3:00 PM on November 5, 2025”. The backend should store this as a UTC instant. New York is EST (UTC−5) on November 5 (DST ended November 2), so the stored value is 2025-11-05T20:00:00Z. A second invitee in Berlin views the same meeting: Berlin is CET (UTC+1) at that date, so the calendar displays 2025-11-05 21:00 CET. A third invitee in Tokyo (UTC+9, no DST) sees 2025-11-06 05:00 JST — same instant, different wall-clocks, all derived from one stored UTC timestamp. Now suppose the meeting recurs weekly: storing “every Wednesday at 20:00 UTC” would silently drift for the New York user when DST ended (they expected 3pm local, would get 4pm local after the November 2 transition). Calendar systems handle this by storing recurring events in the originating zone with the IANA zone name attached, expanding to UTC only at render.

When and why it matters

Almost every “the meeting moved”, “the report ran at the wrong hour”, or “the cron job double-fired across DST” bug traces to storing local time without the zone or to storing the zone offset (+01:00) instead of the zone identifier (Europe/Berlin). The offset is fine for a single instant but becomes ambiguous for any future date — the zone identifier preserves the DST rules. The pragmatic rules: store instants in UTC (or with explicit zone), store user-facing dates with IANA zone identifiers (Europe/Berlin, not +01:00), never use 3-letter zone abbreviations (CST is ambiguous between China, Cuba, and Central US), and let a zone database (tzdata via IANA, updated quarterly) handle the conversion. Reference: IANA Time Zone Database.