How Would You Make a Time-Zone Display Demo?
From the earlier reference collection. Read the current software blog.
A small display demo can render one instant in UTC and a selected local zone while showing explicit offsets and the conversion assumptions.
Begin with one unambiguous instant
A time-zone demo should start with an instant that includes an offset or is explicitly expressed in UTC. A bare value such as 2026-10-28 09:00 is not enough to identify one instant without a zone. Make the input requirement visible so users do not mistake a local clock reading for a globally comparable timestamp.
Parse the input into an instant, then format that same instant twice: once in UTC and once in the selected zone. Keep the selected zone as a named region where possible, because its daylight-saving rules vary over time. A fixed offset alone cannot express those rule changes.
Show the offset beside each clock
Display the UTC date and time with +00:00, and show the local date, time, zone name, and offset. For example, the same instant might display as 17:00 UTC (+00:00) and 10:00 America/Los_Angeles (-07:00) on a date when that zone observes that offset. The exact local result depends on the chosen date and the zone’s rules.
Including the date is essential: converting across zones can move the calendar day. Avoid presenting only 10:00 and 17:00, since users may not know which time belongs to which zone or whether the date changed.
Handle selection and errors clearly
Offer a small list of valid time zones or accept a zone identifier, then report an error for an unknown name. Do not silently fall back to the machine’s local setting; that makes results vary from one computer to another. If the timestamp input omits a zone, ask the user to choose one or reject the value with a clear explanation.
A useful demo can let someone change the selected zone and immediately see the local rendering while the UTC instant stays fixed. If the local time falls near a daylight-saving transition, display the zone’s computed offset for that particular instant rather than assuming a seasonal abbreviation remains correct.
Explain what is being converted
Make clear that the demo converts one instant into two representations; it does not shift an event to a different instant. This distinction matters when scheduling across regions: “09:00 in one location” is a wall-clock intention, while “this UTC timestamp” already identifies a moment.
Test a date in each part of the year, a conversion that crosses midnight, and an instant near a daylight-saving change. The ending display should keep the input instant, UTC rendering, selected zone, local rendering, and offsets together so readers can compare them without guessing.