On 15 January 2026, when it is noon in Abidjan, it is 07:00 in New York, 21:00 in Tokyo, and 04:00 in Los Angeles. The constant in that calculation is the fixed offset from Greenwich Mean Time. Servers do not care about local sunrise. They need a single timeline that never jumps forward in March or back in October. That timeline is GMT, the zero line every other zone is measured from.
The rule is not "use UTC when it suits you." The rule is: store every point in time as UTC, convert only at the display layer. Never let a server's own wall clock drift. Break that rule and you will debug a job that ran twice during the autumn change, or not at all.
Why do servers use GMT instead of local time?
A server in London logging "14:00" and a server in Chicago logging "14:00" are recording two different moments. On 15 January 2026, London is on GMT and Chicago is six hours behind. On 15 July, London is on British Summer Time (UTC+1) and Chicago is five hours behind. The only way to make those log entries comparable is to strip the local offset entirely.
Coordinated Universal Time replaced the older astronomical GMT for technical purposes in 1972, when atomic clocks took over from the Earth's rotation. Today, when a server is configured to "GMT," it is running UTC. That is the correct setting. Cloud providers, database engines, and the Network Time Protocol all default to UTC because it has no daylight saving shifts and no political adjustments. Setting a production server to a local time zone is asking for the same event to be recorded at two different offsets six months apart.
What NTP does and why drift matters
A server set to UTC is only as good as its clock. Hardware clocks drift. NTP, the Network Time Protocol, fixes that by continuously pulling time from a hierarchy of reference sources.
A Stratum 0 device is an atomic clock. A Stratum 1 server reads directly from that clock. A Stratum 2 server reads from a Stratum 1, and so on down the chain. Most public NTP pools deliver Stratum 2 or 3 time. When a server is pointed at an NTP pool, it adjusts its clock in tiny increments, staying within milliseconds of true UTC. Without NTP, a server's notion of GMT is an estimate that gets worse by the day. Financial transaction logs, certificate validity checks, and distributed database writes all depend on this synchronisation.
The Unix clock: seconds from a single starting point
The Unix epoch is midnight, 1 January 1970, 00:00:00 UTC. Every Unix system counts seconds forward from that moment. The count is the same in Abidjan, Monrovia, and São Paulo because it ignores local offsets entirely.
That number is a fixed point in time. A database row stamped with a Unix epoch value does not need a companion column for the time zone. The conversion to a human-readable local time happens once, at the edge, when the value is displayed to a user in New York or Singapore. If the conversion logic uses the IANA zone identifier for that user's location, the displayed time will be correct in January and in July, across any daylight saving boundary.
ISO 8601 and the Z suffix
The same principle applies to the ISO 8601 string format. A timestamp ending in Z (for Zulu, the aviation and military term for UTC) is an unambiguous UTC moment. The string 2026-01-15T12:00:00Z means noon GMT on that date. It does not mean noon in London, which would be 13:00 BST if the date fell in July. The Z suffix is the machine-readable equivalent of "store in UTC."
Which IANA zone should servers use for GMT?
The IANA time zone database is the source of truth for software timekeeping. For GMT, the canonical zone is Etc/GMT. It has a fixed offset of UTC+0 and no daylight saving rules. Other zones in the same metazone include Africa/Abidjan, Africa/Bissau, Africa/Monrovia, Africa/Sao_Tome, America/Danmarkshavn, and Antarctica/Troll. All share the same offset and the same absence of seasonal change.
Hardcoding a numeric offset like +00:00 in application code is fragile. If the zone definition ever changed (unlikely for GMT itself, but common elsewhere), every hardcoded offset would need a patch. Using the IANA identifier Etc/GMT lets the system pull the current definition from the tz database on the host. That database is maintained by the IETF and updated whenever a government changes its time policy.
The Etc/GMT sign trap
The Etc/GMT series has a legacy behaviour that catches developers. POSIX conventions reverse the sign. Etc/GMT-5 means UTC+5, five hours ahead of GMT. Etc/GMT+5 means UTC-5, five hours behind. This is not a bug that will be fixed; correcting it would break existing system configurations that depend on the inverted logic.
The safe path is to use Etc/GMT for the zero offset and named zones such as Europe/London or America/New_York for local display. Avoid the offset variants unless you are writing POSIX system strings and understand the reversal.
How should servers store and display time with GMT?
The industry practice is two steps. Step one: every timestamp enters storage in UTC. Database columns, log files, API responses, message queues. Use a Unix epoch integer or an ISO 8601 string with the Z suffix.
Step two: convert at the display layer. When a user in Mumbai views a timestamp, the application converts the UTC value using the Asia/Kolkata zone. On 15 January 2026, Mumbai is 5.5 hours ahead of GMT. On 15 July, it is still 5.5 hours ahead because India does not observe daylight saving. The conversion logic does not need a seasonal branch; the IANA zone handles it.
Never store a local time without also storing the IANA zone identifier and the UTC offset at that specific moment. A timestamp stored as "15:00, London" in July is ambiguous unless you also record that it was BST (UTC+1). If you omit that, replaying the event six months later will place it at the wrong GMT hour.
Bugs that GMT fixes, and bugs that GMT confusion creates
The most persistent error is treating GMT as synonymous with UK local time. The United Kingdom moves to British Summer Time (UTC+1) from late March to late October. An event scheduled for "14:00 GMT" in July occurs at 15:00 in London. Saying "14:00 UTC" or "14:00 GMT" removes the ambiguity. Saying "London time" does not.
A second error is using the server's own wall clock to generate timestamps. A server in Abidjan, which stays on GMT year-round, will produce correct UTC values if it uses local time. The same code running on a server in London will be wrong by one hour during BST. The fix is to generate timestamps in UTC explicitly, never by reading local time from the operating system unless you are certain the system clock is set to UTC.
A third error is the Etc/GMT sign reversal described above. It silently offsets every stored moment by the wrong number of hours. Testing time zone logic against a date in July, when daylight saving is active in the northern hemisphere, catches most of these bugs before they reach production.
Why West African servers have an easier time
Servers in Ivory Coast, Ghana, Liberia, and Guinea-Bissau operate on GMT with no seasonal clock changes. Abidjan, with a population of 6,321,017, stays on Africa/Abidjan all year. The same is true for Monrovia (population 1,542,549) and Bissau (population 439,704). A server in any of these cities never experiences the one-hour jump that a London server does. The local wall clock and UTC are identical every day of the year. That removes an entire class of scheduling bugs.
How aviation, finance, and broadcasting depend on GMT
Aviation uses GMT (called Zulu time) for all flight plans, NOTAMs, and air traffic control coordination. A clearance issued at "14:00Z" means the same instant whether the aircraft is over Johannesburg or Singapore. Maritime navigation and NATO operations use the same convention.
Financial markets reference GMT for session opens and trade timestamps. The London forex session opens at 08:00 GMT in winter. When London is on BST, the open shifts to 07:00 GMT to keep the local start time consistent. Traders working across London and New York rely on the GMT timestamp to reconcile trades during the overlap window.
Broadcasters, including the BBC World Service, publish schedules in GMT. Shortwave and satellite feeds use GMT so that a programme listed for 18:00 GMT reaches listeners in different zones at a predictable moment. Amateur radio operators log contacts in UTC for the same reason: a QSO recorded at 22:00 UTC is verifiable regardless of the operator's location.
Why GMT is the fixed reference servers rely on
GMT is not a relic. It is the zero line that every other offset is measured against. A server running UTC, synchronised by NTP, storing Unix timestamps or ISO 8601 strings with a Z, and converting to local time only at the display edge will not produce the daylight saving bugs that fill bug trackers every March and October. The IANA zone Etc/GMT is the correct identifier for that fixed reference. Use it, avoid the sign-reversed offset variants, and never assume that "GMT" means "the current time in London."