A time zone is a named set of civil time rules, including changes in its offset from Coordinated Universal Time (UTC), distinct from a fixed offset. Europe/Dublin is one such name: an identifier published in the Internet Assigned Numbers Authority (IANA) Time Zone Database. A UTC offset is a fixed difference from UTC at one moment, such as +01:00. A timezone offset is that same difference, and so is a time offset. Greenwich Mean Time (GMT) is the label in the offset strings below, so GMT+01:00 means one hour ahead of UTC. Daylight saving time (DST) is a seasonal clock change, and it is one reason a single time zone uses more than one UTC offset in a year.

One name, more than one difference

These offsets were read with Intl.DateTimeFormat and the IANA data in this runtime, at 12:00 UTC on the 15th of each month in 2026. Asia/Kolkata stayed at GMT+05:30, India Standard Time. Africa/Lagos stayed at GMT+01:00, West Africa Time. Europe/Dublin, Europe/London, Europe/Paris, and America/New_York each used two offsets across those twelve instants.

Zone15 January 2026, 12:00 UTC15 July 2026, 12:00 UTC
Europe/Dublin12:00, GMT+00:00, Greenwich Mean Time13:00, GMT+01:00, Irish Standard Time
Europe/London12:00, GMT+00:00, Greenwich Mean Time13:00, GMT+01:00, British Summer Time
Europe/Paris13:00, GMT+01:00, Central European Standard Time14:00, GMT+02:00, Central European Summer Time
Africa/Lagos13:00, GMT+01:00, West Africa Time13:00, GMT+01:00, West Africa Time
America/New_York07:00, GMT-05:00, Eastern Standard Time08:00, GMT-04:00, Eastern Daylight Time
Asia/Kolkata17:30, GMT+05:30, India Standard Time17:30, GMT+05:30, India Standard Time

On 15 January, Europe/Paris and Africa/Lagos share GMT+01:00. They are different time zones: on 15 July, Paris is GMT+02:00 and Lagos is still GMT+01:00. Europe/Dublin and Europe/London share an offset on every sampled 15th, while the July names differ: Irish Standard Time and British Summer Time. Asia/Kolkata shows that an offset need not be a whole hour. GMT+05:30 is still one difference from UTC, and on these twelve instants the zone did not change it.

The same split shows up inside one day. On 25 October 2026, Europe/Dublin displays local 01:30 twice. At 2026-10-25T00:30:00Z the offset is GMT+01:00. At 2026-10-25T01:30:00Z the offset is GMT+00:00. On 29 March 2026 the local clock moves from 01:00 GMT+00:00 at 2026-03-29T00:59:00Z to 02:00 GMT+01:00 at 2026-03-29T01:00:00Z, so 01:30 local does not occur. When “due today” has two clocks follows that repeated hour. The offset tells the two 01:30 readings apart. The time zone is the rule set that says the repetition will happen.

A stored offset forgets the next one

An instant that has already happened can be written with the offset that was in force. On 14 November 2026, 10:00 in Europe/Dublin is 2026-11-14T10:00:00Z, offset GMT+00:00. That timestamp says when it happened. It does not say which zone produced the offset.

A future or repeating local time needs the zone. Take an invented weekly meeting at 10:00 in Europe/Dublin. On 14 November 2026 that local time is 10:00 UTC, because the offset is GMT+00:00. On 15 July 2026 the same local 10:00 is 09:00 UTC, because the offset is GMT+01:00: 12:00 UTC is 13:00 local that day, so 10:00 local is one hour earlier in UTC. Store only GMT+00:00, apply it again in July, and the occurrence kept at “10:00 plus that stored offset” lands at 10:00 UTC, which is 11:00 Irish Standard Time. The meeting moved by an hour. The stored difference did not.

Keep the zone identifier for a future or recurring civil time, and derive the offset when an instant is required. Keep the instant for something that already happened, and keep the offset beside it when the local display, or an ambiguous clock change, has to be reconstructed. A city or a country does not supply that name. The Repair Day model keeps Europe/Dublin on the event, the reservation, and the place.

What the TimeZone entity stores

The example catalog's TimeZone entity is a regional convention for local civil time. It has three fields. id holds an identifier such as Europe/Dublin. name is the label people read. offset is one difference from UTC, the difference at a stated moment.

The published time zone entity describes the rule set and does not declare a single offset attribute, because the offset changes. Its time zone identifier names the rules in a stated time zone naming system, such as the IANA Time Zone Database. Its time zone label is a human-readable label. Its time zone description says where or why those rules are used. Put Europe/Dublin in the identifier, name the naming system, and use the label for display.

An event has an event start and an event end: a date and time interpreted with its stated time zone or offset. The event time zone points at the named rules. A place can carry a place time zone, and a reservation can carry a reservation time zone. A date is a calendar day with no time of day, so it carries neither a zone nor an offset. An event has more than a timestamp keeps the plan, the occurrence, and the recorded instant as separate records. The zone belongs with the local plan. The offset belongs with one instant.

Time zoneUTC offset
What it isNamed civil time rules, such as Europe/DublinA fixed difference from UTC at one moment, such as GMT+01:00
How manyOne identifier can produce several offsets when the rules changeOne difference, at one moment
Who else can share itAnother zone keeps its own identifierParis and Lagos both read GMT+01:00 on 15 January 2026 at 12:00 UTC
A future local 10:00Store the time zone and derive the offsetA stored offset from an earlier date applies the old difference
MeaningGraphTime zone, with identifier, naming system, label, and description. Example catalog: id, name, offsetThe example catalog's offset field. The published entity declares no single offset attribute