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.
| Zone | 15 January 2026, 12:00 UTC | 15 July 2026, 12:00 UTC |
|---|---|---|
| Europe/Dublin | 12:00, GMT+00:00, Greenwich Mean Time | 13:00, GMT+01:00, Irish Standard Time |
| Europe/London | 12:00, GMT+00:00, Greenwich Mean Time | 13:00, GMT+01:00, British Summer Time |
| Europe/Paris | 13:00, GMT+01:00, Central European Standard Time | 14:00, GMT+02:00, Central European Summer Time |
| Africa/Lagos | 13:00, GMT+01:00, West Africa Time | 13:00, GMT+01:00, West Africa Time |
| America/New_York | 07:00, GMT-05:00, Eastern Standard Time | 08:00, GMT-04:00, Eastern Daylight Time |
| Asia/Kolkata | 17:30, GMT+05:30, India Standard Time | 17: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 zone | UTC offset | |
|---|---|---|
| What it is | Named civil time rules, such as Europe/Dublin | A fixed difference from UTC at one moment, such as GMT+01:00 |
| How many | One identifier can produce several offsets when the rules change | One difference, at one moment |
| Who else can share it | Another zone keeps its own identifier | Paris and Lagos both read GMT+01:00 on 15 January 2026 at 12:00 UTC |
| A future local 10:00 | Store the time zone and derive the offset | A stored offset from an earlier date applies the old difference |
| MeaningGraph | Time zone, with identifier, naming system, label, and description. Example catalog: id, name, offset | The example catalog's offset field. The published entity declares no single offset attribute |