لماذا يعرض تطبيقك المبني بالذكاء الاصطناعي الوقت الخطأ (وكيف تصلح مشكلة المناطق الزمنية)

لماذا يعرض تطبيق مبني بالذكاء الاصطناعي الوقت الخطأ؟

لأن شخصين في مكانين مختلفين يمكن أن ينظر كلاهما إلى الوقت الصحيح ويريا رقمين مختلفين تمامًا — هذا التباين هو جوهر مشكلة المناطق الزمنية بأكملها. عميل في مدريد يحجز الموعد الساعة 3:00 عصرًا؛ وأنت في مكسيكو سيتي، وتظهر شاشتك نفس الحجز الساعة 8:00 صباحًا. تحدّق في الشاشة متأكدًا أن هناك خللًا ما.

لا شيء معطّل. الساعة 3:00 عصرًا في مدريد هي نفسها 8:00 صباحًا في مكسيكو سيتي، في اللحظة ذاتها بالضبط. كلاكما على صواب. هذه الفجوة — حيث يرى شخصان مُحقّان رقمين مختلفين — هي السبب وراء عدد مفاجئ من بلاغات الأعطال التي عنوانها “تطبيقي يتصرف بغرابة”.

تتسلل إليك هذه المشكلة لأنك أثناء البناء والاختبار تكون الشخص الوحيد، في مكان واحد، وعلى جهاز واحد. كل شيء يتطابق. لا تُظهر المناطق الزمنية أنيابها إلا عندما ينظر شخص آخر، في مكان مختلف، إلى الوقت نفسه. فإن كان لتطبيقك مستخدمون في أكثر من مدينة — أو كان يرسل أي نوع من الرسائل المجدولة — فهذه المشكلة قادمة إليك لا محالة. من الأفضل أن تواجهها عن قصد.

ما هي المنطقة الزمنية بالضبط؟

المنطقة الزمنية هي نصف “المكان” من الوقت — الجزء الذي يحوّل لحظة كونية واحدة إلى قراءة ساعة محلية. وإليك الفكرة الوحيدة التي تجعل كل ما تبقى مفهومًا: لكل وقت جزآن.

1. اللحظة — نقطة زمنية واحدة، هي نفسها في كل مكان على الأرض.
2. المكان — أين أنت عندما تقرأ الساعة.

“3:00 عصرًا” وحدها بلا معنى. 3:00 عصرًا أين؟ تتعامل أجهزة الحاسوب مع هذا بتخزين اللحظة بصيغة محايدة لا تحمل مكانًا (سمعت مسبقًا مصطلح “UTC” — فكّر فيه كساعة عند نقطة مرجعية ثابتة)، ثم تعرضها بتوقيت كل شخص المحلي عندما ينظر إليها.

عندما يعرض التطبيق الوقت الخطأ، يكون السبب غالبًا أنه فقد أحد هذين الجزأين — إما نسي المكان، أو لم يخزّن أصلًا لحظة زمنية حقيقية.

ما الذي يسبب أخطاء المناطق الزمنية في التطبيقات؟

ثلاثة أخطاء محددة تتسبب في معظم أخطاء المناطق الزمنية: تخزين قراءة ساعة بدل لحظة زمنية حقيقية، وعرض المنطقة الزمنية للخادم بدل منطقة المستخدم، وتجاهل تحولات التوقيت الصيفي.

1. التطبيق يخزّن قراءة ساعة، لا لحظة زمنية. يختار شخص ما “9:00 صباحًا” فيحفظ التطبيق النص “9:00 صباحًا” من دون أي مكان مرفق به. والآن يعرض “9:00 صباحًا” للجميع، في كل مكان — وهذا أحيانًا ما تريده بالضبط (تذكير بموعد دواء يجب أن يُطلق الساعة 9 صباحًا بالتوقيت المحلي لكل شخص)، وأحيانًا كارثة (ندوة مباشرة عبر الإنترنت يجب أن تبدأ في لحظة واحدة بالضبط بالنسبة للجميع). فإن أخطأ التطبيق في تخمين أيّهما تقصد، ينحرف الوقت.

2. التطبيق يعرض وقت الخادم، لا وقت المستخدم. يعمل تطبيقك على جهاز حاسوب في مركز بيانات — لنقل في فرجينيا. وإن لم يُخبره أحد بغير ذلك، فسيعرض بكل بساطة توقيت فرجينيا للجميع. الآن أصبح مستخدموك في لندن متأخرين بفارق ساعات كاملة عن الحقيقة، دون أن يعرفوا السبب.

3. التوقيت الصيفي يحرّك الساعات وتطبيقك لا يلاحظ ذلك. مرتين كل عام، تُحرّك أماكن كثيرة ساعاتها بمقدار ساعة واحدة. اجتماع متكرر “كل ثلاثاء الساعة 9:00 صباحًا” أعددته في الشتاء يصبح فجأة الساعة 8:00 أو 10:00 في الصيف، إن كان التطبيق مربوطًا بفارق توقيت ثابت بدل أن يكون مربوطًا بمكان.

ثلاثة أمثلة واقعية على ذلك

الفعالية التي بدأت ثلاث مرات. بنى أحد المؤسسين صفحة بسيطة لورشة عمل عبر الإنترنت مكتوبًا عليها وقت بدء واحد: “تبدأ الساعة 6:00 مساءً.” قرأ الحاضرون في ثلاث دول عبارة “6:00 مساءً” كلٌّ حسب توقيته المحلي الخاص. انضمّ ثلثهم متأخرين بساعة، وانضمّ قلة منهم مبكرين بساعة، ولام الجميع الرابط. لم يكن الحل رابطًا أفضل — بل عرض وقت البدء المحلي الخاص بكل شخص، مع ذكر المنطقة الزمنية بوضوح.

النشرة البريدية التي وصلت الساعة 2:00 فجرًا. كانت رسالة بريد إلكتروني مُعدّة على أن “تُرسَل كل صباح الساعة 8:00” تُرسَل فعليًا الساعة 8:00 بتوقيت الخادم. وبالنسبة للنصف الأوروبي من القائمة البريدية، كان ذلك في منتصف الليل. كانت معدلات فتح الرسالة لدى هؤلاء المشتركين كئيبة، وبدا الأمر وكأنه مشكلة في المحتوى. لكنها كانت مشكلة منطقة زمنية.

الأحد ذو الحجز المزدوج. سمح تطبيق حجز مواعيد لشخصين بحجز نفس موعد جلسة التدليك في الليلة التي “تأخرت” فيها الساعات، لأن الساعة 1:30 فجرًا تكررت مرتين تلك الليلة، وعامَلها التطبيق باعتبارهما اللحظة نفسها. أمر نادر الحدوث، لكنه من نوع الأخطاء التي تكلفك عميلًا حقيقيًا واعتذارًا حقيقيًا.

ما الذي يجب أن تطلبه من أداة البناء لإصلاح مشكلة المناطق الزمنية؟

اطلب أربعة أمور محددة، بلغة بسيطة — لست بحاجة لتعلّم أي من هذا بالتفصيل. انسخ ما يلي:

“خزّن كل وقت كلحظة بتوقيت UTC، وخزّن أيضًا المنطقة الزمنية لكل مستخدم.”

“عندما تعرض وقتًا، اعرضه بتوقيت المستخدم الذي يشاهده، وضع المنطقة الزمنية بجانبه مباشرة — مثل 3:00 مساءً (بتوقيتك) أو 3:00 PM CST.”

“بالنسبة لكل ما يتكرر — التذكيرات، الجداول، الفعاليات المتكررة — اربطه بمكان (مثل ‘America/Mexico_City’)، لا بعدد ساعات ثابت، حتى يُعالَج التوقيت الصيفي تلقائيًا.”

“دعني أختبره وكأنني في بلد آخر.”

هذا الطلب الأخير أهم مما يبدو عليه، وهو ما يقودنا إلى الجزء الذي يمكنك القيام به بنفسك.

كيف تختبر تطبيقك بحثًا عن أخطاء المناطق الزمنية؟

يمكنك اكتشاف معظم أخطاء المناطق الزمنية في دقيقتين فقط، دون الحاجة لمستخدم في بلد آخر — فقط تظاهر بأنك هناك:

1. افتح إعدادات التاريخ والوقت في هاتفك أو حاسوبك، وغيّر المنطقة الزمنية إلى مكان بعيد — طوكيو، لندن، أي مكان.
2. أعد تحميل تطبيقك.
3. انظر إلى كل مكان يظهر فيه وقت. هل ما زال منطقيًا؟ هل يخبرك لمن هذا الوقت؟

إن كان حجزًا من المفترض أن يكون الساعة 3:00 عصرًا، وأصبح يظهر الآن الساعة 4:00 فجرًا من دون أي تفسير، فأنت وجدت الخطأ قبل أن يجده أحد عملائك. أعد إعدادات جهازك كما كانت عند الانتهاء. أما بالنسبة لحالات التذكير المتكرر والتوقيت الصيفي، فأضمن طريقة للتحقق هي أن تطلب من صديق في بلد آخر أن ينظر إلى تاريخ واحد ويخبرك بالوقت الذي يراه.

هل تحتاج أصلًا للقلق بشأن المناطق الزمنية؟

بصراحة — أحيانًا لا، ويستحق الأمر أن يُقال. فإن كان كل من يستخدم تطبيقك في نفس المدينة — كأداة جدولة موظفي مطعم محلي، أو تسجيل في نادٍ في الحي — يمكنك في الغالب تجاوز الأجزاء الصعبة. فقط كن ثابتًا واذكر المنطقة الزمنية بوضوح حتى لا يبقى مجال للشك.

تصبح المناطق الزمنية مصدر قلق حقيقي في اللحظة التي يتحقق فيها أحد أمرين: شخصان في مكانين مختلفين يتشاركان وقتًا واحدًا، أو تطبيقك يرسل أي شيء وفق جدول زمني. وفي اللحظة التي تتجاوز فيها هذا الحد، يكون أرخص تأمين هو الأبسط أيضًا: اعرض دائمًا المنطقة الزمنية بجانب الوقت. هذه العادة وحدها تزيل الغموض الذي يسبب معظم هذه القصص، حتى قبل أن تصل الإصلاحات الأعمق.

لذا في المرة القادمة التي تضيف فيها حقل تاريخ أو وقت إلى تطبيقك، اسأل نفسك سؤالًا واحدًا قبل أن تمضي قدمًا: لمن هذا الوقت؟ فإن استطعت الإجابة عن هذا السؤال بصوت عالٍ، فأنت بالفعل متقدم على معظم التطبيقات التي يبنيها الناس.