طلب أُجري الساعة 3:40 عصرًا يظهر «تاريخ الإنشاء» فيه 9:40 صباحًا هو نوع الأخطاء الذي يفقد الثقة في النظام بسرعة؛ لا لأنه يعطل شيئًا وظيفيًا، بل لأن كل طابع زمني على كل شاشة يصبح شيئًا على الفريق تصحيحه في ذهنه.
إيجاد الفرق الفعلي
كان الفرق ثابتًا عند ست ساعات، وهو بالضبط الفرق بين UTC والتوقيت الرسمي لبنغلاديش (UTC+6)، وهو مؤشر قوي حتى قبل فتح شاشة الإعدادات. كانت المنطقة الزمنية لموقع WordPress مضبوطة على UTC بدلًا من Asia/Dhaka، ما يعني أن كل طابع زمني تنشئه المنصة أو تعرضه كان صحيحًا تقنيًا بتوقيت UTC وخاطئًا لأي شخص يقرؤه بالتوقيت المحلي.
إعداد واحد، لكن هناك سؤال يستحق الطرح أولًا
كان الإصلاح نفسه تغييرًا واحدًا في الإعدادات → عام. أما السؤال الأهم فكان: هل يجب أن يرافقه ترحيل للبيانات، أي هل يجب إعادة كتابة الطوابع الزمنية المحفوظة للطلبات الحالية أيضًا؟ والإجابة في حالة WooCommerce: لا؛ فالطوابع الزمنية للطلبات تُخزَّن داخليًا بتوقيت UTC وتُحوَّل إلى المنطقة الزمنية المضبوطة للموقع عند العرض، مع كل تحميل للصفحة. تصحيح إعداد الموقع صحّح فورًا الوقت المعروض لكل طلب موجود بأثر رجعي، دون الحاجة إلى تغيير أي شيء في قاعدة البيانات.
أهم الدروس
- الفرق الثابت بعدد ساعات كامل يشير في الغالب إلى خطأ في إعداد المنطقة الزمنية لا إلى خطأ في الكود؛ فقارن الفرق بفروق UTC المعروفة أولًا.
- معرفة ما إذا كانت المنصة تخزّن البيانات بتوقيت UTC وتحوّلها عند العرض، أم تخزّن وقتًا محليًا محوّلًا مسبقًا، تخبرك فورًا ما إذا كان إصلاح الإعداد وحده كافيًا.
- أحيانًا تكون أصغر الإصلاحات هي الأجدر بالكتابة عنها: تغيير إعداد واحد بأثر حقيقي ورجعي على المتجر كله.
اقرأ أيضًا: خطأ 403 متقطع سببه مدة التخزين المؤقت، ما الذي تشمله صيانة المواقع فعلًا.
هل تواجه قيدًا مشابهًا في لوحة إدارة WooCommerce أو WordPress لديك؟ لنتحدث؛ فـ ArtinTech Solution تبني هذا النوع تحديدًا من أدوات المتاجر المخصصة.