AddThisFeature

Locale-Aware Numbers and Dates

Show and read dates, numbers, and money the way each user writes them.

moderate Accessibility & Internationalization

What it adds

A shared formatting and parsing layer so numbers, currency, percentages, dates, and times render and are read correctly per locale and time zone.

What your agent is told to do

6
  1. 1

    Find every place the app formats a number, currency, percentage, date, or time, and route them through one shared helper instead of scattered format strings.

  2. 2

    Store and transmit locale-neutral values: ISO 8601 timestamps in UTC, and numbers as numbers. Format only at the point of display.

  3. 3

    Format currency with the currency's own decimal rules and the locale's symbol placement — some currencies have no decimal places and some put the symbol after the amount.

  4. 4

    Parse user input against the active locale so that typing 1.000,50 is read as one thousand and a half, and reject ambiguous input with a clear message rather than guessing.

  5. 5

    Render dates and times in the user's stored time zone, and show the zone anywhere a time is actionable such as a meeting or a deadline.

  6. 6

    Do NOT use a bare numeric date format like 03/04/2026 anywhere it matters. It reads as two different days on two continents; use an abbreviated month name instead.

Edge cases it handles

7
  • Do not assume the browser time zone is the user's — a traveller's laptop lies. Store an explicit preference and let them change it.
  • Daylight saving transitions mean a day is not always 24 hours; date arithmetic done in UTC and displayed locally will drift by an hour twice a year.
  • Relative times such as 'in 3 hours' go stale on a page left open; refresh them or use an absolute time in tooltips.
  • Never do money arithmetic in floating point. Work in minor units and format at the end.
  • Right-to-left locales still render digits left to right; do not manually reverse numeric strings.
  • A number input on mobile shows a keypad matching the browser locale, which may not match the app's active locale — accept both separators where it is unambiguous.
  • Sorting and grouping by date must use the user's time zone, or rows land in the wrong day bucket near midnight.

Definition of done

9
  • All display formatting goes through one shared layer.
  • Stored and transmitted values are locale-neutral, UTC where applicable.
  • Currency respects per-currency decimal rules and per-locale symbol placement.
  • Typed input is parsed against the active locale, and ambiguous input is rejected with a clear message.
  • Times display in the user's stored time zone, with the zone shown for actionable times.
  • No ambiguous all-numeric date format appears in the interface.
  • Monetary calculations use minor units, not floats.
  • 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.