तारीख़, संख्या, मुद्रा और टाइम ज़ोन

यह क्यों ज़रूरी है

ये defects सीधे पैसे और भरोसे की कीमत लेते हैं। गलत क्रम में parse हुई date 4 March की जगह 3 April की flight book कर देती है। गलत decimal separator से parse हुई amount 1.500 को डेढ़ riyal या पंद्रह सौ बना देती है। UTC day से grouped report Riyadh में 00:30 पर रखे गए order को पिछले दिन में दिखाती है, इसलिए daily totals bank से कभी नहीं मिलते। जब rule total पर rounding कहता हो तब हर line पर round की गई VAT invoice को accounting records से एक halala (riyal का सौवाँ हिस्सा) अलग कर देती है, और फिर किसी को यह फ़र्क़ ढूँढकर समझाना पड़ता है।

Tester के लिए मुश्किल यह है कि ये defects उसके अपने environment में दिखते ही नहीं। Riyadh से English browser में आपको Western digits, बिना daylight saving time का +03:00 zone और एक calendar दिखता है। Jeddah का user Arabic-Indic digits और Hijri calendar के साथ, Kolkata का user +05:30 पर और London का user जिसकी घड़ी March में बदलती है, ऐसे failures से टकराते हैं जो आपने कभी पैदा ही नहीं किए। Locale और time zone को browser या device की तरह जान-बूझकर test conditions के रूप में चुनना पड़ता है।

एक value, कई presentations

हर locale-sensitive value की एक canonical form होती है जिसे product को store और transmit करना चाहिए: instant ISO 8601 (या RFC 3339, जो internet protocols के लिए उसकी profile है) में UTC या explicit offset के साथ, 2026-03-04T21:30:00Z या 2026-03-05T00:30:00+03:00; number dot वाला सादा decimal, 1234567.89; amount एक decimal और ISO 4217 currency code, {"amount": "42.95", "currency": "SAR"}। Presentation edge पर एक formatting library बनाती है जो Unicode CLDR project के locale data पर टिकी है: browsers और Node.js में Intl API, Android और iOS पर ICU (International Components for Unicode) पर आधारित APIs।

Locale एक BCP 47 language tag है: en-US, en-GB, ar-SA, hi-IN। Language subtag शब्द और नाम चुनता है; region subtag digits, separators, calendar और हफ़्ते के पहले दिन के defaults बदलता है। Currency इनमें नहीं है: वह amount के साथ उसके ISO 4217 code के रूप में चलती है। Unicode extensions किसी default को explicitly override करते हैं: ar-SA-u-nu-latn Western digits माँगता है, ar-SA-u-ca-islamic-umalqura Umm al-Qura calendar, hi-IN-u-nu-deva Devanagari digits। Figure दिखाता है कि एक date, एक number और एक amount की presentations कितनी दूर चली जाती हैं जबकि stored values बिल्कुल नहीं बदलतीं।

• Stored: क्या canonical value सही और unambiguous है, अपने offset या zone और currency code के साथ?
• Displayed: क्या हर supported locale इसे library के ज़रिए render करता है, उन digits, separators, calendar और symbol के साथ जो product ने तय किए?
• Entered: क्या user के अपने format में टाइप की गई value उसी locale से parse होती है, normalise होती है या साफ़ message के साथ reject होती है, और कभी चुपचाप गलत नहीं पढ़ी जाती?

Dates, calendars और time zones

Date presentation के तीन स्वतंत्र आयाम हैं। हिस्सों का क्रम: 3/4/26 en-US में 4 March है और 04/03/2026 en-GB में 4 March, इसलिए string 03/04/2026 दोनों में अलग दिन बताती है। Digits और नाम: Arabic-Indic digits, localised महीनों के नाम, और Levantine Arabic (ar-JO, ar-SY) में March को آذار कहते हैं जबकि Saudi Arabic में مارس। Calendar: Saudi Arabia में Umm al-Qura calendar Gregorian के साथ-साथ चलता है, 4 March 2026 15 Ramadan 1447 AH है, और Hijri महीना 29 या 30 दिन का होता है, इसलिए दोनों calendars के month ends अलग पड़ते हैं।

Time zone locale का हिस्सा नहीं है: वह user, device या account का होता है। Instant समय का एक बिंदु है; उसका wall-clock time और यहाँ तक कि calendar day भी zone पर निर्भर है। Asia/Riyadh बिना daylight saving time का UTC+03:00 है, Asia/Kolkata UTC+05:30, Asia/Kathmandu UTC+05:45, और Europe/London व America/New_York साल में दो बार अपना offset बदलते हैं। Instants को UTC में या explicit offset के साथ store करें, zones को offset से नहीं बल्कि उनके IANA नाम से पहचानें, सिर्फ़ display के लिए convert करें, और उन पलों को test करें जहाँ दिन बदलता है।

• Test values: दोनों calendars में महीने और साल का आख़िरी दिन, 29 February 2028, user के zone में 23:59 और 00:00, और daylight saving time लागू करने वाले zone के change days।
• Date-only values जैसे date of birth या due date का कोई zone नहीं होता और server या देखने वाला कहीं और हो तो वे shift नहीं होनी चाहिए।
• Seconds और milliseconds वाले timestamps आपस में उलझ जाते हैं: हज़ार गुना छोटी value January 1970 में जा गिरती है, हज़ार गुना बड़ी दूर भविष्य के किसी साल में।

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.

आज़माएँ: ISO 8601 कन्वर्टर आज़माएँ: टाइमस्टैम्प कन्वर्टर आज़माएँ: तारीख़ टेस्ट डेटा जनरेटर

Numbers, digits और currency

Number presentation में एक digit system और दो separators होते हैं: en-US 1,234,567.89 लिखता है, de-DE 1.234.567,89, fr-FR narrow no-break space के साथ 1 234 567,89, hi-IN भारतीय grouping में 12,34,567.89, जहाँ पहले तीन अंकों के बाद हर group दो अंकों का होता है (एक lakh = 1,00,000 यानी 100,000, और एक crore = 1,00,00,000 यानी 10 million), ar-SA Arabic-Indic digits और Arabic separators U+066C व U+066B के साथ ١٬٢٣٤٬٥٦٧٫٨٩। इसलिए एक ही string के अलग मतलब हैं: 1.500 en-US में डेढ़ है और de-DE में पंद्रह सौ। Input उसी locale से parse होना चाहिए जिसमें user ने टाइप किया, और Arabic-Indic digits पर runtimes एकमत नहीं हैं: JavaScript में Number("٥٠٠") NaN देता है, जबकि Python में int("٥٠٠") 500 लौटाता है। इसलिए product को तय करना होगा, और requirement में लिखना होगा, कि ऐसे digits 0–9 में normalise होंगे या साफ़ message के साथ reject होंगे।

पैसा currency और rounding rule जोड़ देता है। Amount एक decimal और ISO 4217 code है, और ISO 4217 हर currency की minor unit भी देता है, यानी decimal places की संख्या: SAR और INR के लिए दो, JPY के लिए शून्य, KWD, BHD, JOD और OMR के लिए तीन, इसलिए "दो decimals" कोई universal rule नहीं है। Binary floating point ज़्यादातर decimal amounts को exact नहीं रख सकता: JavaScript में 0.1 + 0.2 से 0.30000000000000004 मिलता है और 3 * 12.45 से 37.349999999999994। Amounts की जगह minor units के integers या decimal type में है, और requirement को बताना होगा कि rounding कहाँ और किस rule से होती है। Symbol और उसकी position locale से आती है, template से नहीं: en-US में SAR 1,500.00, de-DE में 1.500,00 SAR, ar-SA में ١٬٥٠٠٫٠٠ ر.س., जहाँ string के दोनों सिरों पर right-to-left marks (U+200F) और symbol से पहले no-break space भी होता है, इसीलिए हाथ से टाइप की expected string fail होती है जबकि screen सही दिखती है। Screen पर यही marks amount और उसके symbol को Latin या neutral text के बगल में भी right-to-left क्रम में रखते हैं, इसलिए ر.س. number के बाईं ओर दिखता है, हालाँकि string में खुद digits पहले आते हैं; इसके पीछे का Unicode Bidirectional Algorithm roadmap का अगला step, RTL testing guide, समझाती है।

• Identifiers quantities नहीं हैं: phone numbers, IBANs, order numbers और national ID numbers कभी grouped, rounded या localised digits में नहीं दिखाए जाते।
• -42.95 का refund ठीक उसी तरह round होना चाहिए जैसे वह charge जिसे वह reverse करता है; minus sign और percent sign कहाँ लगेंगे और उनके आसपास कौन-से invisible marks होंगे, यह भी locale तय करता है।
• अलग currencies की amounts कभी न जोड़ें; SAR और INR lines को जोड़ने वाला total data का defect है, formatting का सवाल नहीं।

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.

आज़माएँ: डेसिमल डेटासेट जनरेटर आज़माएँ: अरबी टेस्ट डेटा जनरेटर

Worked example: एक order, तीन users

Order API नीचे दिया record लौटाता है। तीन लोग confirmation page खोलते हैं: Jeddah में Noura (ar-SA, product settings में Western digits चुने हुए, zone Asia/Riyadh), Kolkata में Priya (hi-IN, Asia/Kolkata) और London में finance team (en-GB, Europe/London)। हर expected value stored record से उसी library के ज़रिए निकाली जाती है जो product इस्तेमाल करता है, याद से कभी नहीं टाइप की जाती।

• Noura: order 5 March 2026 को 00:30 पर रखा गया; total 42.95 ر.س., Western digits क्योंकि setting यही कहती है, symbol ar-SA formatter की तय जगह पर, और पूरी string right-to-left paragraph में सही।
• Priya: order 5 March 2026 को 03:00 पर; total SAR 42.95, ISO code क्योंकि hi-IN formatter riyal के लिए code दिखाता है और product currencies convert नहीं करता।
• Finance: order 4 March 2026 को 21:30 पर; total SAR 42.95। 4 March की daily report में यह order शामिल है जबकि Noura की order list इसे 5 March के नीचे दिखाती है; दोनों सही हैं, और report के header में उसका zone लिखा होना चाहिए।
• जिन defects की तलाश करें: Noura के page पर 4/3/2026 या 3/5/2026 (UTC day, या en-US क्रम), VAT 5.61 (हर line पर rounded), setting में Western digits होने के बावजूद ٤٢٫٩٥, template से चिपकाया SAR42.95 जिससे हर locale को एक ही string दिखे, और page के अपनी ही formatted string को दोबारा parse करने के बाद बदला हुआ total।

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

आज़माएँ: Timezone कन्वर्टर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• Unicode CLDR ProjectUnicode ConsortiumCommon Locale Data Repository: तारीख़, समय, संख्या व मुद्रा फ़ॉर्मेट और plural नियमों का locale डेटा जिसे ज़्यादातर प्लेटफ़ॉर्म इस्तेमाल करते हैं।
• Time Zone DatabaseIANAदुनिया के time zone और उनके ऐतिहासिक offset व daylight-saving नियमों का tz डेटाबेस, जो साल में कई बार अपडेट होता है।
• ISO 4217 — Currency codesISOतीन-अक्षरी मुद्रा कोड (SAR, INR, USD…) और उनकी minor units — मुद्रा फ़ील्ड और फ़ॉर्मेटिंग टेस्ट का संदर्भ।
• RFC 3339: Date and Time on the Internet: TimestampsIETF · 2002ISO 8601 का इंटरनेट टाइमस्टैम्प प्रोफ़ाइल (2026-09-23T10:15:00Z) और उसके ऑफ़सेट नियम।