AIM Tech

🔥 Timezone Nightmares…(Context) الوقت مش رقم… الوقت سياق 😅

واحد من أخطر أنواع البجز
اللي بتعدي في التستنج عادي جدًا…
وبعدين تظهر أول ما اليوزر يغيّر البلد.

المشكلة اسمها:
Timezone Handling

🧠 المشكلة فين؟

السيرفر غالبًا شغال بـ UTC.
الموبايل شغال بتوقيت الدولة.
الويب ممكن يعتمد على Browser Time.

ولو مفيش اتفاق واضح…
كل واحد بيحسب بطريقته.

🎯 مثال عملي جدًا:

API بترجع تاريخ بداية الاشتراك:

2026-05-01T00:00:00

السؤال 👀
ده UTC؟
ولا Local Time؟
ولا مفيش Timezone أصلاً؟

لو مفيش Z أو Offset واضح
الموبايل هيفسره حسب توقيته.

نتيجة؟
يوزر في مصر يشوف الاشتراك بدأ 1 مايو.
يوزر في السعودية يشوفه 30 أبريل مساءً.
يوزر في أمريكا يشوفه 30 أبريل الصبح!

نفس الداتا…
3 تواريخ مختلفة.

🎯 مثال أقوى (بيحصل فعلًا):

Flash Sale تبدأ 1 مايو الساعة 00:00.

السيرفر مخزنها UTC.
الفرونت بيقارنها بوقت الجهاز.

يوزر في +3 timezone
يشوف العرض بدأ بدري 3 ساعات.

يوزر في -5
يشوفه متأخر 5 ساعات.

والكارثة؟
مفيش Error ظاهر.

🎯 مثال تقيل شوية:

تقرير مبيعات “ليوم 1 مايو”.

لو الاستعلام بيعمل:

WHERE date = '2026-05-01'

من غير تحديد timezone

النتيجة تختلف حسب:

السيرفر فين
الداتا متخزنة بإيه
المستخدم فين

ممكن أوردر الساعة 11:30 مساءً
يتحسب في يوم مختلف تمامًا.

🧨 المشكلة الأخطر:

لما التوقيت يتغير بسبب:

Daylight Saving Time
تغيير البلد
تغيير Timezone في الموبايل يدويًا

Features زي:

OTP Expiry
Subscription Expiry
Session Timeout

تبدأ تتصرف بغرابة.

💡 كـ Tester لازم تسأل:
هل التواريخ مخزنة بـ UTC؟
هل الـ API بترجع Offset واضح؟ (+02:00 مثلًا)
هل الفرونت بيحوّل التوقيت صح؟
هل في مقارنة بين وقتين من مصدرين مختلفين؟
هل جربت تغير Timezone الجهاز؟

🎯 تمرين احترافي:

وأنت بتست أي API فيها تاريخ
اعمل 3 حاجات:

1️⃣ غير Timezone الجهاز
2️⃣ ابعت Request بإيدك بتوقيت مختلف
3️⃣ قارن الرد على جهازين في بلدين مختلفين

لو النتيجة اختلفت…
عندك Timezone Bug مستني يتكشف 👀🔥

الوقت مش مجرد رقم…
الوقت Context.

ولو السيستم مش فاهم الـ Context
هيحسبه غلط بثقة كاملة 😌
لو عجبك موضوعنا النهارده ماتنساش تزور موقعناhttps://aimtech.online/posts وخدلك لفة في محتوي يساعدك تكون سابق بخطوة 💪

🔥 From Value Boundaries to Time Boundaries: The Missing Dimension in Testing

في بوست فات اتكلمنا إن البجز بتحب تختبئ عند حدود الـ values… وازي مهم تختبر ال Boundaries والنهارده هنشوف إن في نوع أخطر من الحدود: حدود الزمن نفسه ⏳

إنت ممكن تختبر كل السيناريوهات صح…بس تنسى حاجة واحدة:

الوقت.

والوقت في السيستم مش ثابت.
بيتغير… وبيكسر الدنيا 👀

🧨 ليه الـ Time Bugs خطيرة؟

لأنها:

مش دايمًا تتكرر
بتحصل في تواريخ معينة
أو ساعات معينة
أو عند انتقالات زمنية

وأحيانًا… تظهر مرة في السنة بس!

🎯 مثال بسيط لكنه قاتل:

Feature اشتراك ينتهي بعد 30 يوم.

السؤال:
30 يوم من إمتى؟

من لحظة الدفع؟
من بداية اليوم؟
حسب UTC؟
حسب توقيت جهاز المستخدم؟

لو اليوزر في مصر
والسيرفر UTC
والتاريخ اتحسب غلط

ممكن الاشتراك ينتهي بدري…
أو يفضل شغال زيادة.

🎯 مثال أقوى:

حجز فندق من 1 مايو لـ 3 مايو.

هل يوم 3 محسوب؟
ولا الخروج صباحًا؟
ولا لحد 11:59 مساءً؟

فرق بسيط في التفسير
= ليلة زيادة أو ناقصة.

🎯 مثال Production حقيقي بيتكرر كل سنة:

سيستم بيحسب العمر تلقائيًا.

شخص مولود 29 فبراير 👀
في سنة مش كبيسة…
يتحسب عمره إزاي؟

28 فبراير؟
1 مارس؟
ولا يحصل Error؟

🎯 مثال أخطر في السيستمات الكبيرة:

Flash Sale تبدأ الساعة 12:00.

موبايل اليوزر الساعة 11:59
السيرفر 12:00
CDN متأخر ثواني

ناس تشوف العرض شغال
ناس تشوفه مقفول
ناس تدفع ويتخصم منها
والأوردر يترفض.

ده مش Bug Validation.
ده Bug توقيت.

🧠 كـ Tester اسأل:
السيستم بيستخدم أي Time Zone؟
هل بيتم التخزين بـ UTC؟
هل في اختلاف بين وقت السيرفر والعميل؟
هل في Caching مرتبط بالوقت؟
إيه اللي يحصل عند Midnight؟
إيه اللي يحصل آخر الشهر؟
إيه اللي يحصل نهاية السنة؟

🎯 أهم قاعدة:

أي Feature مرتبطة بـ:

Expiry
Subscription
Booking
Offer
OTP
Reports

لازم تختبرها على “حافة الوقت”.

لأن البج مش بيظهر الساعة 2 الضهر…
هو بيستنى الساعة 11:59 👀🔥

البوست الجاي هنتعمق أكتر ف كونسبت الوقت وازاي الوقت مش مجرد رقم .. ده بيختلف ع حسب السياق
بس لحد البوست الجاي ما توقفش .. زور موقعنا https://aimtech.online/posts وكمل رحلتك في فضاء السوفتوير تيستنج 🚀