التواريخ والأرقام والعملات والمناطق الزمنية

لماذا يهم

تكلّف هذه العيوب المال والثقة مباشرةً. فتاريخ يُحلَّل بترتيب خاطئ يحجز رحلة في ⁦3⁩ أبريل بدلاً من ⁦4⁩ مارس. ومبلغ يُحلَّل بفاصلة عشرية خاطئة يحوّل 1.500 إلى ريال ونصف أو إلى ألف وخمسمئة. وتقرير مجمَّع حسب يوم UTC يضع طلباً سُجّل الساعة ⁦00:30⁩ بتوقيت الرياض في اليوم السابق، فلا تتطابق المجاميع اليومية مع البنك أبداً. وضريبة قيمة مضافة تُقرَّب لكل سطر بينما تنص القاعدة على تقريبها على الإجمالي تجعل الفاتورة تختلف عن السجلات المحاسبية بهللة واحدة (جزء من مئة من الريال)، ثم على أحدٍ أن يبحث عن هذا الفرق ويفسّره.

وصعوبة الأمر على المختبِر أن هذه العيوب غير مرئية في بيئته هو. فمن الرياض بمتصفح إنجليزي ترى أرقاماً غربية ومنطقة زمنية ⁦+03:00⁩ بلا توقيت صيفي (Daylight Saving Time) وتقويماً واحداً. أما المستخدم في جدة بالأرقام العربية المشرقية (Arabic-Indic digits) والتقويم الهجري، والمستخدم في كولكاتا عند ⁦+05:30⁩، والمستخدم في لندن الذي تتغيّر ساعته في مارس، فيواجهون إخفاقات لم تظهر لك قط. لذلك يجب اختيار الإعداد المحلي والمنطقة الزمنية عمداً كشروط اختبار، مثل المتصفح أو الجهاز.

قيمة واحدة وطرق عرض كثيرة

لكل قيمة حساسة للإعداد المحلي صيغة قانونية ينبغي للمنتج أن يخزنها وينقلها: اللحظة الزمنية بصيغة ISO 8601 (أو RFC 3339، وهي صيغة مقيَّدة منها لبروتوكولات الإنترنت) بتوقيت UTC أو بفارق صريح، 2026-03-04T21:30:00Z أو 2026-03-05T00:30:00+03:00؛ والعدد كسر عشري بسيط بنقطة، 1234567.89؛ والمبلغ كسر عشري مع رمز عملة من ISO 4217، {"amount": "42.95", "currency": "SAR"}. أما طريقة العرض فتُنتَج عند الطرف بمكتبة تنسيق مبنية على بيانات مشروع CLDR من يونيكود: واجهة Intl في المتصفحات وNode.js، والواجهات المبنية على ICU (International Components for Unicode) في Android وiOS.

والإعداد المحلي وسم لغة من BCP 47: en-US وen-GB وar-SA وhi-IN. فالجزء اللغوي يختار الكلمات والأسماء، والجزء الإقليمي يعدّل الافتراضات للأرقام والفواصل والتقويم وأول أيام الأسبوع. أما العملة فليست منها: فهي ترافق المبلغ رمزاً من ISO 4217. وتتجاوز امتدادات يونيكود الافتراضات صراحةً: ar-SA-u-nu-latn يطلب الأرقام الغربية، وar-SA-u-ca-islamic-umalqura تقويم أم القرى، وhi-IN-u-nu-deva أرقام الديفاناغاري. ويوضح الشكل كم تتباعد طرق عرض تاريخ واحد وعدد واحد ومبلغ واحد بينما لا تتغير القيم المخزنة إطلاقاً.

• المخزَّن: هل القيمة القانونية صحيحة وغير غامضة، مع فارقها أو منطقتها الزمنية ورمز عملتها؟
• المعروض: هل يعرضها كل إعداد محلي مدعوم عبر المكتبة، بالأرقام والفواصل والتقويم والرمز التي قرّرها المنتج؟
• المُدخَل: هل تُحلَّل القيمة المكتوبة بصيغة المستخدم بذلك الإعداد المحلي، وتُطبَّع أو تُرفض برسالة واضحة، ولا تُقرأ خطأً بصمت أبداً؟

التواريخ والتقاويم والمناطق الزمنية

لعرض التاريخ ثلاثة أبعاد مستقلة. ترتيب الأجزاء: 3/4/26 هو ⁦4⁩ مارس في en-US و04/03/2026 هو ⁦4⁩ مارس في en-GB، لذا تسمّي السلسلة 03/04/2026 يوماً مختلفاً في كل منهما. والأرقام والأسماء: الأرقام العربية المشرقية، وأسماء الأشهر المترجمة، وفي عربية الشام (ar-JO وar-SY) يُسمّى مارس «آذار» بينما تستخدم العربية في السعودية «مارس». والتقويم: في السعودية يسير تقويم أم القرى جنباً إلى جنب مع التقويم الميلادي، فيوم ⁦4⁩ مارس ⁦2026⁩ هو ⁦15⁩ رمضان ⁦1447⁩ هـ، والشهر الهجري ⁦29⁩ أو ⁦30⁩ يوماً، لذلك تختلف نهايات الأشهر بين التقويمين.

والمنطقة الزمنية ليست جزءاً من الإعداد المحلي: فهي تتبع المستخدم أو الجهاز أو الحساب. واللحظة نقطة واحدة في الزمن، لكن وقتها على الساعة بل ويومها في التقويم يعتمدان على المنطقة. فـAsia/Riyadh هي ⁦UTC+03:00⁩ بلا توقيت صيفي، وAsia/Kolkata هي ⁦UTC+05:30⁩، وAsia/Kathmandu هي ⁦UTC+05:45⁩، أما Europe/London وAmerica/New_York فيغيّران فارقهما مرتين في السنة. خزّن اللحظات بتوقيت UTC أو بفارق صريح، وسمِّ المناطق بأسمائها في IANA لا بفارق، وحوّل للعرض فقط، واختبر اللحظات التي يتغيّر فيها اليوم.

• قيم الاختبار: آخر يوم في الشهر وفي السنة في التقويمين، و⁦29⁩ فبراير ⁦2028⁩، و⁦23:59⁩ و⁦00:00⁩ بمنطقة المستخدم، وأيام التغيير في منطقة تطبّق التوقيت الصيفي.
• القيم التي هي تاريخ فقط، مثل تاريخ الميلاد أو تاريخ الاستحقاق، ليست لها منطقة زمنية ويجب ألا تنزاح عندما يكون الخادم أو القارئ في مكان آخر.
• الطوابع الزمنية بالثواني وبالميلي ثانية تختلط: قيمة أصغر ألف مرة تقع في يناير ⁦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 جرّبها: محوّل الطوابع الزمنية جرّبها: مولّد بيانات اختبار التواريخ

الأعداد والأرقام والعملات

لعرض العدد نظام أرقام وفاصلتان: فـen-US يكتب 1,234,567.89، وde-DE 1.234.567,89، وfr-FR 1 234 567,89 بمسافة ضيقة غير فاصلة، وhi-IN 12,34,567.89 بالتجميع الهندي، حيث تتكوّن كل مجموعة بعد الخانات الثلاث الأولى من خانتين (اللاك الواحد ⁦1,00,000⁩ أي مئة ألف، والكرور الواحد ⁦1,00,00,000⁩ أي عشرة ملايين)، وar-SA ١٬٢٣٤٬٥٦٧٫٨٩ بالأرقام العربية المشرقية والفاصلتين العربيتين U+066C وU+066B. ولذلك تحمل السلسلة نفسها معانيَ مختلفة: 1.500 واحد ونصف في en-US وألف وخمسمئة في de-DE. ويجب تحليل المُدخل بالإعداد المحلي الذي كتب به المستخدم، وبيئات التشغيل لا تتفق في التعامل مع الأرقام العربية المشرقية: ففي JavaScript تعطي Number("٥٠٠") القيمة NaN، بينما تعيد int("٥٠٠") في Python العدد ⁦500⁩. لذلك على المنتج أن يقرر، وعلى المتطلب أن ينص، هل تُطبَّع هذه الأرقام إلى ⁦0–9⁩ أم تُرفض برسالة واضحة.

ويضيف المال العملة وقاعدة التقريب. فالمبلغ كسر عشري مع رمز من ISO 4217، ويحدد ISO 4217 أيضاً الوحدة الصغرى (Minor unit) لكل عملة، أي عدد المنازل العشرية: منزلتان للريال السعودي SAR وللروبية INR، ولا شيء للين JPY، وثلاث للدينار الكويتي KWD والبحريني BHD والأردني JOD وللريال العماني OMR، لذا «منزلتان عشريتان» ليست قاعدة عامة. والفاصلة العائمة الثنائية (Binary floating point) لا تستوعب معظم المبالغ العشرية بدقة: في JavaScript يعطي 0.1 + 0.2 القيمة 0.30000000000000004 ويعطي 3 * 12.45 القيمة 37.349999999999994. فمكان المبالغ أعداد صحيحة بالوحدات الصغرى أو نوع عشري، ويجب أن يذكر المتطلب أين يحدث التقريب وبأي قاعدة. ويأتي رمز العملة وموضعه من الإعداد المحلي لا من قالب: SAR 1,500.00 في en-US، و1.500,00 SAR في de-DE، و١٬٥٠٠٫٠٠ ر.س. في ar-SA، حيث تحمل السلسلة أيضاً علامتَي اتجاه من اليمين إلى اليسار (U+200F) في طرفيها ومسافة غير فاصلة قبل الرمز، ولهذا تفشل السلسلة المتوقعة المكتوبة يدوياً بينما تبدو الشاشة صحيحة. وعلى الشاشة تُبقي العلامتان نفسهما المبلغ ورمزه بترتيب من اليمين إلى اليسار حتى بجوار نص لاتيني أو محايد الاتجاه، فيظهر ر.س. على يسار الرقم مع أن الأرقام تأتي أولاً في السلسلة نفسها؛ ويشرح دليل اختبار واجهات اليمين إلى اليسار، وهو الخطوة التالية في خريطة التعلم، خوارزمية يونيكود ثنائية الاتجاه (Unicode Bidirectional Algorithm) التي تقف وراء ذلك.

• المعرِّفات ليست كميات: أرقام الهواتف وأرقام IBAN وأرقام الطلبات وأرقام الهوية لا تُجمَّع ولا تُقرَّب ولا تُعرض بأرقام محلية أبداً.
• استرداد بقيمة ⁦-42.95⁩ يجب أن يُقرَّب تماماً كما قُرِّب المبلغ الذي يعكسه؛ وموضع علامة السالب وعلامة النسبة المئوية، والعلامات غير المرئية حولهما، يأتي من الإعداد المحلي أيضاً.
• لا تجمع أبداً مبالغ بعملات مختلفة؛ فإجمالي يجمع سطوراً بالريال SAR وأخرى بالروبية INR عيب في البيانات لا مسألة تنسيق.

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.

جرّبها: مولّد مجموعات الأرقام العشرية جرّبها: مولّد بيانات الاختبار العربية

مثال تطبيقي: طلب واحد وثلاثة مستخدمين

تعيد واجهة الطلبات السجل أدناه. ويفتح صفحة التأكيد ثلاثة أشخاص: نورة في جدة (ar-SA مع أرقام غربية اختارتها في إعدادات المنتج، والمنطقة Asia/Riyadh)، وبريا في كولكاتا (hi-IN وAsia/Kolkata)، وفريق المالية في لندن (en-GB وEurope/London). وكل قيمة متوقعة تُستخرج من السجل المخزَّن بالمكتبة نفسها التي يستخدمها المنتج، ولا تُكتب من الذاكرة أبداً.

• نورة: سُجّل الطلب في ⁦5⁩ مارس ⁦2026⁩ الساعة ⁦00:30⁩؛ الإجمالي 42.95 ر.س. بأرقام غربية لأن الإعداد يقول ذلك، والرمز في موضعه الذي يحدده منسِّق ar-SA، والسلسلة كلها صحيحة داخل فقرة من اليمين إلى اليسار.
• بريا: سُجّل الطلب في ⁦5⁩ مارس ⁦2026⁩ الساعة ⁦03:00⁩؛ الإجمالي SAR 42.95 برمز ISO، لأن منسِّق hi-IN يعرض الريال بهذا الرمز والمنتج لا يحوّل العملات.
• المالية: سُجّل الطلب في ⁦4⁩ مارس ⁦2026⁩ الساعة ⁦21:30⁩؛ الإجمالي SAR 42.95. ويحتوي التقرير اليومي ليوم ⁦4⁩ مارس هذا الطلب، بينما تعرضه قائمة طلبات نورة تحت ⁦5⁩ مارس؛ وكلاهما صحيح، ويجب أن يذكر عنوان التقرير منطقته الزمنية.
• عيوب تبحث عنها: 4/3/2026 أو 3/5/2026 في صفحة نورة (يوم UTC، أو ترتيب en-US)، وضريبة 5.61 (مقرَّبة لكل سطر)، و٤٢٫٩٥ مع أن الإعداد يقول أرقاماً غربية، وSAR42.95 ملصوقة بقالب بحيث يرى كل إعداد محلي السلسلة نفسها، وإجمالي يتغيّر بعد أن تعيد الصفحة تحليل سلسلتها المنسَّقة.

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

جرّبها: محوّل المناطق الزمنية

أسئلة شائعة

المراجع

• Unicode CLDR ProjectUnicode Consortiumمستودع بيانات اللغات والمناطق المشترك: بيانات صيغ التاريخ والوقت والأرقام والعملات وقواعد الجمع التي تعتمدها معظم المنصات.
• Time Zone DatabaseIANAقاعدة بيانات tz للمناطق الزمنية في العالم وقواعد فروق التوقيت والتوقيت الصيفي تاريخياً، وتُحدَّث عدة مرات في السنة.
• ISO 4217 — Currency codesISOرموز العملات ثلاثية الأحرف (SAR وINR وUSD…) ووحداتها الفرعية — المرجع لاختبار حقول العملة وتنسيقها.
• RFC 3339: Date and Time on the Internet: TimestampsIETF · 2002ملف تعريف الطوابع الزمنية على الإنترنت المشتق من ISO 8601 (2026-09-23T10:15:00Z) وقواعد الإزاحة الزمنية.