كائن Date في جافاسكريبت قنبلة موقوتة في أنظمة الإنتاج. تعتمد على طوابع زمنية بالميلي ثانية منذ حقبة Unix (1 يناير 1970 UTC)، لكن التصميم ينقصه الدقة اللازمة للتعامل الآمن مع التواريخ. النتيجة؟ فواتير بيوم واحد مختلف، تجديدات اشتراكات في الشهر الخاطئ، وفوضى في الجداول الزمنية.
6 أعطال تحطّم الإنتاج
1. فخ تحويل UTC إلى العرض المحلي
عندما تُنشئ `new Date('2026-07-21')`، يفسرها جافاسكريبت كـ UTC، لكن عند العرض تنزاح بيوم واحد في المناطق الزمنية غرب UTC. السبب: الطابع الزمني يُختزل برقم الساعات، وهذا قد يعبر منتصف الليل. مثلاً: `2026-07-21T00:00:00Z` (UTC) تصبح `2026-07-20T18:00:00` في UTC-6. النتيجة: التقارير والفواتير تظهر ليوم مختلف.
الحل الآمن: أضف المنطقة الزمنية صراحةً: `new Date('2026-07-21T00:00:00+00:00')`
الحل الأمثل: استخدم Temporal API: `Temporal.PlainDate.from('2026-07-21[UTC]')`
2. مفاجأة أغسطس: الشهور بفهرسة 0
`new Date(2026, 7, 21)` تُنشئ 21 أغسطس، وليس يوليو، لأن الفهرسة تبدأ من 0. هذا عدم توافق بين ما يتوقعه البشر (شهور 1-12) وما تفعله الواجهة البرمجية. فاتورة قد تُسجل في الشهر الخاطئ بسبب هذا.
الحل الآمن: استخدم parsing النصوص: `new Date('2026-07-21')`
الحل الأمثل: Temporal.PlainDate.from({ year: 2026, month: 7, day: 21
}) — شهور 1-based
3. خطأ المراجع المشتركة: Mutability يفسد البيانات
طرق مثل `setMonth` أو `setDate` تعدّل كائن Date في المكان. إذا أشارت عدة متغيرات لنفس الكائن، التعديلات تؤثر عليها جميعاً. في بيئات غير متزامنة، هذا مصدر صامت لفساد البيانات.
const d1 = new Date();
const d2 = d1;
d2.setMonth(0); // د1 و د2 أصبحا الآن في يناير!الحل الآمن: انسخ قبل التعديل: `const d2 = new Date(d1.getTime())`
الحل الأمثل: استخدم Temporal.PlainDate — كائنات غير قابلة للتغيير
4. حساب الشهور مقابل الأيام: الاختلاف عند الحدود
إضافة شهر واحد وإضافة 30 يوماً يختلفان عند حدود الشهور. إضافة 30 يوم لـ 2026-01-31 ينتج 2026-03-02، لكن إضافة شهر واحد تعطي 2026-02-28. هذا يكسر دورات التجديد والفواتير.
الحل الآمن: استخدم مكتبات محققة مثل `date-fns`
الحل الأمثل: Temporal.PlainDate.add({ months: 1 })
5. فقدان المنطقة الزمنية الصامت في JSON
`JSON.stringify` يسلسل كائنات Date كنصوص ISO بدون معلومات المنطقة الزمنية (مثل `"2026-07-21T00:00:00.000Z"`). هذا يرغم العملاء على تخمين المنطقة الزمنية الأصلية، مما يؤدي لأخطاء في الأنظمة الموزعة.
الحل الآمن: أضف الـ offset يدويًا: `date.toISOString().replace('Z', '+00:00')`
الحل الأمثل: `Temporal.PlainDate.toString()` يحافظ على السياق
6. غموض البناء: مصيدة التحليل
`new Date(2026, 0, 1)` تُنشئ 2026-01-01، لكن `new Date(2026, 0, 1, 0, 0, 0, 0)` تُعامل كمنطقة زمنية محلية بشكل افتراضي، مما يسبب عدم توافق إذا كان المقصود UTC.
الحل الآمن: استخدم parsing النصوص مع منطقة زمنية محددة
الحل الأمثل: Temporal.PlainDateTime.from({ year: 2026, month: 1, day:
1, timeZone: 'UTC' })
الخلاصة: Temporal API هو المستقبل
Temporal API ليست مجرد غلاف — إنها إعادة تصميم أساسية. بفرض الـ immutability، معالجة المنطقة الزمنية الصريحة، والحسابات المتسقة، تزيل الأسباب الجذرية لأخطاء Date. القاعدة واضحة: إذا كانت الدقة والموثوقية غير قابلة للتفاوض، استخدم Temporal للأكواد الجديدة.
للأنظمة الموروثة، فرض أنماط آمنة إلزامي. لكن هذه ليست حلاً — إنها ضمادة على نظام مكسور. الحل الحقيقي هو الهجرة.
