No transition occurs in this named zone during the selected year.
Before and after show the boundary labels at the exact UTC transition. A missing or repeated local label still requires an explicit choice in the planner.
Why an identifier matters
An offset describes one moment. A named zone carries the date-specific rules used to calculate each meeting.
Planning dates run from Thu, Jan 1, 2026 through Mon, Dec 31, 2035. Future rules can be revised; review the data version when a distant schedule matters.
Asia/Dubai uses UTC+04:00 on all four displayed dates. That makes the 2026 examples simple to read, but the saved identifier still matters. Time-zone data can be revised; a named location records the policy you intend to follow instead of assuming a numeric offset is permanent.
Offsets in the bundled rules
Sampled at 12:00 UTC on each date, using IANA 2026f.
Date
UTC offset
Display abbreviation
2026-01-15
UTC+04:00
+04
2026-07-15
UTC+04:00
+04
2026-10-27
UTC+04:00
+04
2026-11-03
UTC+04:00
+04
Resolve the wall time before exporting
At 13:00 in this zone on 27 October 2026, UTC is 09:00 and Asia/Kolkata is 14:30. The conversion has a unique result in this example. The neighboring half-hour difference is preserved in both start and end times.
Use this identifier in a plan
Find Asia/Dubai in the zone directory or choose Dubai from the city directory. Add the other meeting locations, enter their availability, and check the complete duration. The supported planning years are 2026–2035; future political rule changes may require a new data version.
A calendar export uses the resolved UTC start and end times. The zone remains part of the planning context, while the exported instant stays unambiguous when another calendar displays it in its own time zone.