Dates, Numbers, Currency and Time Zones

Why it matters

These defects cost money and trust directly. A date parsed in the wrong order books a flight on 3 April instead of 4 March. An amount parsed with the wrong decimal separator turns 1.500 into one and a half riyals or into fifteen hundred. A report grouped by UTC day puts an order placed at 00:30 in Riyadh on the previous day, so the daily totals never reconcile with the bank. VAT rounded per line when the rule says on the total makes an invoice one halala (a hundredth of a riyal) off from the accounting records, and someone then has to find and explain that difference.

For a tester the difficulty is that these defects are invisible in your own environment. From Riyadh with an English browser you see Western digits, a +03:00 zone without daylight saving time and one calendar. The user in Jeddah with Arabic-Indic digits and the Hijri calendar, the user in Kolkata at +05:30 and the user in London whose clocks change in March hit failures you never provoked. Locale and time zone must be chosen deliberately as test conditions, like a browser or a device.

One value, many presentations

Every locale-sensitive value has a canonical form that the product should store and transmit: an instant as ISO 8601 (or RFC 3339, its profile for internet protocols) in UTC or with an explicit offset, 2026-03-04T21:30:00Z or 2026-03-05T00:30:00+03:00; a number as a plain decimal with a dot, 1234567.89; an amount as a decimal plus an ISO 4217 currency code, {"amount": "42.95", "currency": "SAR"}. The presentation is produced at the edge by a formatting library built on the locale data of the Unicode CLDR project: the Intl API in browsers and Node.js, APIs based on ICU (International Components for Unicode) on Android and iOS.

A locale is a BCP 47 language tag: en-US, en-GB, ar-SA, hi-IN. The language subtag picks words and names; the region subtag adjusts the defaults for digits, separators, calendar and first day of the week. The currency is not one of them: it travels with the amount as its ISO 4217 code. Unicode extensions override a default explicitly: ar-SA-u-nu-latn asks for Western digits, ar-SA-u-ca-islamic-umalqura for the Umm al-Qura calendar, hi-IN-u-nu-deva for Devanagari digits. The figure shows how far the presentations of one date, one number and one amount drift apart while the stored values do not change at all.

• Stored: is the canonical value correct and unambiguous, with its offset or zone and its currency code?
• Displayed: does every supported locale render it through the library, with the digits, separators, calendar and symbol the product decided on?
• Entered: is a value typed in the user's own format parsed with that locale, normalised or rejected with a clear message, and never silently misread?

Dates, calendars and time zones

A date presentation has three independent dimensions. The order of the parts: 3/4/26 is 4 March in en-US and 04/03/2026 is 4 March in en-GB, so the string 03/04/2026 names a different day in each. The digits and names: Arabic-Indic digits, localised month names, and in Levantine Arabic (ar-JO, ar-SY) March is آذار where Saudi Arabic uses مارس. The calendar: in Saudi Arabia the Umm al-Qura calendar runs beside the Gregorian one, 4 March 2026 is 15 Ramadan 1447 AH, and a Hijri month has 29 or 30 days, so the month ends of the two calendars differ.

A time zone is not part of the locale: it belongs to the user, the device or the account. An instant is one point in time; its wall-clock time and even its calendar day depend on the zone. Asia/Riyadh is UTC+03:00 without daylight saving time, Asia/Kolkata is UTC+05:30, Asia/Kathmandu is UTC+05:45, and Europe/London and America/New_York change their offset twice a year. Store instants in UTC or with an explicit offset, identify zones by their IANA name rather than by an offset, convert for display only, and test the moments where the day changes.

• Test values: the last day of a month and of a year in both calendars, 29 February 2028, 23:59 and 00:00 in the user's zone, and the change days of a zone that observes daylight saving time.
• Date-only values such as a date of birth or a due date have no zone and must not shift when the server or the viewer is somewhere else.
• Timestamps in seconds and in milliseconds get mixed up: a value a thousand times too small lands in January 1970, a thousand times too large in a far future year.

One instant, stored once:  2026-03-04T21:30:00Z

Zone (IANA)         Offset   Local wall-clock time   Calendar day
UTC                 +00:00   2026-03-04 21:30        4 March
Europe/London       +00:00   2026-03-04 21:30        4 March  (BST from 29 March)
America/New_York    -05:00   2026-03-04 16:30        4 March  (EDT from 8 March)
Asia/Riyadh         +03:00   2026-03-05 00:30        5 March
Asia/Kolkata        +05:30   2026-03-05 03:00        5 March
Asia/Kathmandu      +05:45   2026-03-05 03:15        5 March

A report grouped by "day" lists this order on 4 March in London
and on 5 March in Riyadh. Both are right; the report must name its zone.

Try it: ISO 8601 Converter Try it: Timestamp Converter Try it: Date Test Data Generator

Numbers, digits and currency

A number presentation has a digit system and two separators: en-US writes 1,234,567.89, de-DE 1.234.567,89, fr-FR 1 234 567,89 with a narrow no-break space, hi-IN 12,34,567.89 in the Indian grouping, where the groups after the first three digits have two digits (one lakh is 1,00,000, that is 100,000, and one crore is 1,00,00,000, ten million), ar-SA ١٬٢٣٤٬٥٦٧٫٨٩ with Arabic-Indic digits and the Arabic separators U+066C and U+066B. The same string therefore has different meanings: 1.500 is one and a half in en-US and fifteen hundred in de-DE. Input must be parsed with the locale the user typed in, and runtimes disagree about Arabic-Indic digits: in JavaScript Number("٥٠٠") is NaN, while in Python int("٥٠٠") returns 500. The product must therefore decide, and the requirement must say, whether such digits are normalised to 0–9 or rejected with a clear message.

Money adds a currency and a rounding rule. An amount is a decimal plus an ISO 4217 code, and ISO 4217 also gives each currency's minor unit, the number of decimal places: two for SAR and INR, none for JPY, three for KWD, BHD, JOD and OMR, so "two decimals" is not a universal rule. Binary floating point cannot hold most decimal amounts exactly: in JavaScript 0.1 + 0.2 gives 0.30000000000000004 and 3 * 12.45 gives 37.349999999999994. Amounts belong in integers of minor units or in a decimal type, and the requirement must say where rounding happens and by which rule. The symbol and its position come from the locale, not from a template: SAR 1,500.00 in en-US, 1.500,00 SAR in de-DE, ١٬٥٠٠٫٠٠ ر.س. in ar-SA, where the string also carries right-to-left marks (U+200F) at both ends and a no-break space before the symbol, which is why a hand-typed expected string fails while the screen looks right. On screen the same marks keep the amount and its symbol in right-to-left order even next to Latin or neutral text, so ر.س. appears to the left of the number although the digits come first in the string itself; the RTL testing guide, the next step in the roadmap, explains the Unicode Bidirectional Algorithm behind this.

• Identifiers are not quantities: phone numbers, IBANs, order numbers and national ID numbers are never grouped, rounded or shown in localised digits.
• A refund of -42.95 must round exactly like the charge it reverses; where the minus sign and the percent sign go, and which invisible marks surround them, also comes from the locale.
• Never add amounts in different currencies; a total that sums SAR and INR lines is a data defect, not a formatting question.

Order: 3 x 12.45 SAR, VAT 15 %

Rule A, VAT on the subtotal:  37.35 x 0.15 = 5.6025 -> 5.60            total 42.95
Rule B, VAT per line:         12.45 x 0.15 = 1.8675 -> 1.87 x 3 = 5.61  total 42.96

Both are "15 % VAT rounded to 2 decimals". The requirement must name the rule,
and the test must use amounts on which the two rules differ.

Try it: Decimal Dataset Generator Try it: Arabic Test Data Generator

Worked example: one order, three users

An order API returns the record below. Three people open the confirmation page: Noura in Jeddah (ar-SA with Western digits chosen in the product settings, zone Asia/Riyadh), Priya in Kolkata (hi-IN, Asia/Kolkata) and the finance team in London (en-GB, Europe/London). Every expected value is derived from the stored record with the same library the product uses, never typed from memory.

• Noura: placed on 5 March 2026 at 00:30; total 42.95 ر.س., Western digits because the setting says so, the symbol placed by the ar-SA formatter, the whole string correct inside a right-to-left paragraph.
• Priya: placed on 5 March 2026 at 03:00; total SAR 42.95, the ISO code because the hi-IN formatter shows the code for the riyal and the product does not convert currencies.
• Finance: placed on 4 March 2026 at 21:30; total SAR 42.95. The daily report for 4 March contains this order while Noura's order list shows it under 5 March; both are right, and the report header must name its zone.
• Defects to look for: 4/3/2026 or 3/5/2026 on Noura's page (the UTC day, or en-US order), VAT 5.61 (rounded per line), ٤٢٫٩٥ although the setting says Western digits, SAR42.95 glued together by a template so that every locale sees the same string, and a changed total after the page re-parses its own formatted string.

{
  "order_id": "ORD-2026-0042",
  "placed_at": "2026-03-04T21:30:00Z",
  "subtotal": "37.35",
  "vat": "5.60",
  "total": "42.95",
  "currency": "SAR"
}

Try it: Timezone Converter

Frequently asked questions

References

• Unicode CLDR ProjectUnicode ConsortiumThe Common Locale Data Repository: the locale data for date, time, number and currency formats and plural rules that most platforms use.
• Time Zone DatabaseIANAThe tz database of the world's time zones and their historical offset and daylight-saving rules, updated several times a year.
• ISO 4217 — Currency codesISOThe three-letter currency codes (SAR, INR, USD…) and their minor units — the reference for currency fields and formatting tests.
• RFC 3339: Date and Time on the Internet: TimestampsIETF · 2002The Internet timestamp profile of ISO 8601 (2026-09-23T10:15:00Z) and its offset rules.