AddThisFeature

Time Zone Converter

Show a time in both zones at once so nobody joins an hour late.

simple Accessibility & Internationalization

What it adds

A paired display of any scheduled time in the viewer's zone and the other party's zone.

What your agent is told to do

5
  1. 1

    Find every place the app shows a time that two people in different places need to agree on: booking confirmations, invitations, live sessions, deadlines. Show both zones there rather than one canonical time.

  2. 2

    Detect the viewer's zone from their device on first visit, but store an explicit override on the account and let them change it from settings. Detection is a starting guess, not an answer.

  3. 3

    Label each zone by city and current offset, not by an abbreviation. Several abbreviations mean two different things depending on the country, and the reader cannot tell which one you meant.

  4. 4

    If the app already has Time Zone-Aware Scheduling, take its stored zone data and conversion helpers as the source of truth and add only the paired display. Do not introduce a second, differently behaved notion of what zone a user is in.

  5. 5

    Do not convert by adding a fixed hour offset stored at write time. Offsets change with daylight saving, so a meeting booked in one season silently drifts by an hour in the next.

Edge cases it handles

8
  • The viewer's zone is detected but must always be overridable, and the override must persist across sessions and devices rather than being re-guessed on each visit.
  • Zones are named by city and offset. An abbreviation is ambiguous across countries and leaves the reader unsure which of two times was meant.
  • When the two sides fall on different calendar days, say so explicitly next to the time. A reader who sees only the hour will assume it is the same day and be wrong.
  • Some zones sit at thirty- or forty-five-minute offsets. Any arithmetic or formatting that assumes whole hours will display those times incorrectly.
  • On clock-change days some local times occur twice and some do not occur at all. Warn on both, and resolve the ambiguity explicitly rather than picking one silently.
  • A device with a badly wrong clock or an unrecognised zone must fall back to the stored account zone rather than rendering nothing.
  • Historical times must be converted using the rules that applied on that date, not today's rules, or past records will shift as governments change their zones.
  • The two times must be readable side by side on a narrow screen without one wrapping away from its label.

Definition of done

8
  • Every shared time displays in both the viewer's zone and the other party's zone.
  • The viewer's zone is detected on first use and can be overridden persistently.
  • Zones are labelled by city and current offset, never by a bare abbreviation.
  • A day difference between the two zones is stated explicitly.
  • Non-whole-hour offsets and daylight-saving transitions render correctly, including ambiguous and non-existent local times.
  • Conversions are computed from the stored instant and zone identifier, not from a cached numeric offset.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.