في يوم مشمس جميل في الشغل جالك مشروع برمجة تطبيق لشركة طيران يقدر المستخدم يستعمله في حجز التذاكر, طبعًا فرحت جدًا ما كلنا بنحب السفر لحد ما فكرت في مشكلة التاريخ والوقت وجالك صداع!
هخلي التطبيق يحسب التاريخ والوقت على أساس أنهي دولة؟ طيب هعمل ايه في التوقيت الصيفي؟ وبالنسبة للمناطق الزمنية؟!, طيب ايه اللي هيحصل في السنين الكبيسة!!
مشاكل التعامل مع التاريخ والوقت في صناعة البرمجيات غنية عن التعريف لأن الموضوع فعلاً معقد فورقة وقلم وتعالوا نتعرف على أفضل الطرق للتعامل معها.
1- استخدم مكتبة موثوقة
القاعدة الأهم في موضوع دوال الوقت و التاريخ إنه لازم تستخدم مكتبة موثوق فيها سواء موجودة في اللغة بشكل أساسي زي datetime في python أو java.time في java
ابعد تمامًا عن إعادة اختراع العجلة ومحاولتك لبرمجة الدوال دي بنفسك لأن الساعة كما نعرفها الآن تعرضت لتغييرات تاريخية وسياسية وجغرافية بتخلي موضوع برمجة دوال الوقت والتاريخ بشكل صحيح من الصفر مشروع معقد جدًا.
لازم كمان تضمن إن المكتبة اللي بتستخدمها بتوفر بيانات محدثة ودقيقة عن المناطق الزمنية.
تقدروا دلوقتي تشتركوا في النشرة الأسبوعية لاقرأ-تِك بشكل مجاني تمامًا عشان يجيلكوا كل جديد بشكل أسبوعي فيما يخص مواضيع متنوعة وبشروحات بسيطة وسهلة وبجودة عالية 🚀
النشرة هيكون ليها شكل جديد ومختلف عن شكلها القديم وهنحاول انها تكون مميزة ومختلفة وخليط بين المحتوى الأساسي اللي بينزل ومفاجآت تانية كتير 🎉
2- استخدام الـ UTC لتجنب مشاكل الـ Timezones
ال UTC هو نظام توقيت عالمي موحد بنستخدمه عشان نتجنب الالتباس في الساعات والمناطق الزمنية حوالين العالم, فخلي دايمًا برنامجك معتمد عليه بشكل أساسي بدل ما تستخدم الوقت المحلي للمنطقة أو الدولة اللي أنت فيها. وممكن بسهولة تقدر تعمل formatting ليه عشان يظهر الوقت المحلي للمستخدم.
فكمثال عندما يقوم مستخدم بحجز رحلة من نيويورك (UTC-5) إلى باريس (UTC+1)، يجب على النظام أن يحسب بدقة وقت المغادرة ووقت الوصول في المنطقة الزمنية المحلية.
إذا كانت الرحلة تغادر نيويورك في الساعة 6 مساءً بالتوقيت المحلي وتستغرق 7 ساعات، يجب أن يعرض النظام وقت الوصول في باريس بالتوقيت المحلي الصحيح (الساعة 2 صباحًا بتوقيت باريس).
3- التوقيت الصيفي
احنا خلاص متفقين اننا دايمًا هنخزن التاريخ والوقت بصيغة ال UTC في ال Database ولكن عند تحويل الصيغة لل Local Time Zone ممكن تقابلنا مشكلة التوقيت الصيفي و لذلك لازم المكتبة تكون بتدعم تغييرات التوقيت الصيفي لمنع حدوث أخطاء نتيجة تغيير الساعة.
4- السنوات الكبيسة و الثواني الكبيسة
لازم تتأكد إن المكتبة اللي بتستخدم منها دوال التاريخ والوقت بتتعامل مع السنوات الكبيسة Lead Years ودا أمر بسيط كونه بيحصل بشكل منتظم وبيأثر بشكل ملحوظ, ولكن كمان لو تطبيقك بيحتاج دقة زمنية عالية فهتحتاج تعرف إزاي المكتبة بتتعامل مع الثواني الكبيسة Leap Seconds لأنها بتتضاف بشكل غير منتظم علي ال UTC.
( الحمدلله النوع دا مش شائع الا لو رايح تشتغل في ناسا😂)
5- ISO 8601 Format
هل 04-06-2024 معناها 4 يونيو و لا 6 أبريل ؟ مشكلة التنسيق دي ممكن تخليك تفوت تذكرة الطيارة وتروح المطار بعدها بشهرين 😂.
ممكن نكون متعودين على أن الشهر هو اللي في النص ولكن في أمريكا على سبيل المثال المتعارف عليه ان اليوم هو اللي في النص وعشان نتجنب الالتباس دا بنستخدم ال ISO 8601 Format في شغلنا في الكود ولو حبينا نغير التنسيق عشان يتناسب مع المستخدمين في أمريكا مثلاً فدا بيكون في مرحلة العرض فقط.
6- التدقيق والاختبار و الوضوح
اختيار مكتبة التاريخ والوقت اللي هتعتمد عليها في كل مشروعك أمر مهم تديله وقت وتفكير وبالأخص لو مشاريعك كبيرة وبتعتمد علي الوقت بشكل دقيق, لأن مثلاً لو احتجت اعمل تطبيق بيحتاج دقة بمستوي ال Milliseconds أو ال Micro Seconds زي برمجة الـ Embedded Software, كذلك لو أنا بعمل تطبيق يستخدم Regional Calendar كمثال لو هتعمل تطبيق اسلامي لشهر رمضان فهتحتاج مكتبة بتدعم التقويم الهجري. لو المكتبة لا تدعم الخيارات دي هضطر ابدلها في الكود كله!
كمان مهم اعمل Unit Tests للكود اللي الوقت بيلعب فيه دور محوري واغطي حالات التوقيت الصيفي و السنوات الكبيسة وأشوف الكود بيتعامل معاها إزاي.
بنفكركم بإن ال Unit Tests في حد ذاتها من أحسن طرق ال Documentation ولكن يفضل كمان تكتب ADR اختصار Architecture Decision Record أو Documentation عن أسباب اختياركم كفريق للمكتبة دي وبتقدملكم مميزات ايه و ايه هي الافتراضات الزمنية الموجودة في النظام ككل, الوضوح في الأمر دا هيوفر وقت كتير علي المبرمجين فيما بعد في حل المشكلات المتعلقة بالوقت.