Practise vocabulary for ISO 8601 dates, locale-specific number formats, timezone handling, and currency display.
0 / 5 completed
1 / 5
Why is 04/08/2026 ambiguous as a date format?
Date format ambiguity is a real-world bug source. Solution: use ISO 8601 (2026-04-08) for data storage and APIs; display in the user's locale format only in the UI. Never store or exchange dates as MM/DD/YYYY — always parse to a date object and format for display.
2 / 5
ISO 8601 date format is always expressed as:
ISO 8601 dates (2026-04-08) are: unambiguous regardless of locale, sortable alphabetically (because year-month-day is most-to-least significant), and the correct format for APIs, databases, and data exchange. Always use ISO 8601 in backend code; format for display only at the presentation layer.
3 / 5
The phrase 'number grouping varies by locale — 1,234,567.89 in US vs. 1.234.567,89 in Germany' means:
Number format varies dramatically: US (1,234.56), Germany (1.234,56), France (1 234,56), Switzerland (1'234.56). The correct approach: use Intl.NumberFormat() in JavaScript (or equivalent ICU library) with the user's locale — never format numbers with hardcoded separators.
4 / 5
The best practice 'store all timestamps in UTC; format them in the user's local timezone only at display time' solves which problem?
Common bugs from local timezone storage: logs appear to go back in time during DST fall-back (two 1:30am entries), dates shift when a user in one timezone views data entered by someone in another timezone, analytics aggregations are incorrect. UTC storage + local-timezone display is universal best practice.
5 / 5
The Intl.NumberFormat API (or ICU NumberFormat) should be used for currency display because:
Examples: USD $1,234.56 (US); 1.234,56 $ (some EU locales); ¥1,234 (Japan, no decimal); 1 234,56 € (France). new Intl.NumberFormat('fr-FR', {style:'currency', currency:'EUR'}).format(1234.56) → '1 234,56 €'. Hardcoded '$' + number.toFixed(2) is wrong for non-US users.