يبدو تمثيل اللحظة الراهنة مسألة تافهة حتى تحاول فعل ذلك في نظام حاسوبي. فما معنى «الآن» بالضبط؟ وكيف تعبّر عنه بطريقة يفهمها كل نظام بالطريقة نفسها؟ يقدّم زمن يونكس إجابة أنيقة: عدّ الثواني المنقضية منذ لحظة مرجعية ثابتة. هذا الرقم البسيط يوفّر خطًّا زمنيًّا مشتركًا يتجاوز المناطق الزمنية واللغات. لكن خلف بساطته تكمن قرارات حول الدقّة، والثواني الكبيسة، وجودة الساعة، والتفسير، لا يجوز تجاهلها.

فكرة بسيطة: عدّ الثواني من نقطة مرجعية

جوهر زمن يونكس هو اختيار لحظة مرجعية واحدة، ثم التعبير عن أيّ لحظة لاحقة بعدد الثواني التي مرّت منذئذ. هذا يحوّل الزمن إلى رقم واحد، لا إلى مزيج من سنة وشهر ويوم وساعة ومنطقة زمنية. الرقم الواحد سهل التخزين، وسهل المقارنة، وسهل النقل.

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

خطّ زمنيّ محايد للمناطق الزمنية

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

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

مسألة الدقّة

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

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

الثواني الكبيسة وتعقيد الواقع

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

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

جودة الساعة التي تنتج الرقم

الطابع الزمنيّ لا يكون أدقّ من الساعة التي ولّدته. وساعات الحاسوب ليست مثالية: قد تنحرف، أو تُضبَط فجأة، أو تقفز إلى الوراء عند مزامنتها. الاعتماد على ساعة الحائط لقياس الفترات قد يعطي نتائج غريبة إذا تغيّرت الساعة في أثناء القياس.

لهذا تميّز الأنظمة الدقيقة بين ساعة الحائط، التي تمثّل الوقت المدنيّ وقد تقفز، وساعة رتيبة تتقدّم دائمًا إلى الأمام وتصلح لقياس المدد. استعمال الساعة الخطأ لمهمّة ما مصدر علل دقيقة في القياس والترتيب.

الطابع الزمنيّ ليس تاريخًا بشريًّا

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

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

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

حدود التمثيل ومشكلة الفيض

لكلّ تمثيل رقميّ سقفٌ لا يتجاوزه. فحين يُخزَّن عدد الثواني في حقل ذي حجم محدود، يأتي يومٌ يتجاوز فيه الرقم سعة الحقل فيلتفّ إلى قيمة سالبة، فينقلب «المستقبل البعيد» فجأة إلى «ماضٍ سحيق». هذه ليست مسألة نظرية، بل سبب معروف لأعطاب جسيمة في أنظمة بُنيت على حقول ضيّقة دون انتباه لحدودها.

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

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

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

التفسير يبقى مسؤوليتك

الرقم وحده لا يعني شيئًا دون اتّفاق على تفسيره. هل هو بالثواني أم المللي ثانية؟ وهل يمثّل لحظة مطلقة أم وقتًا محلّيًّا؟ وما اللحظة المرجعية المفترضة؟ هذه الأسئلة يجب أن تكون لها إجابات واضحة ومشتركة بين كل من ينتج الطابع ويستهلكه.

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