هذا المقال يتطلب مستوى: مبتدئ

لو الموعد اللي خزّنته الساعة 3 بيظهر لمستخدم في بلد تاني الساعة 5، المشكلة مش في السيرفر ولا في المستخدم. انت بتخزّن وقت من غير ما تقول هو بأي منطقة زمنية. المقال ده هيخلّيك تخزّن الوقت صح مرة واحدة وتريّح دماغك.

التوقيت وUTC: ليه الوقت بيلعب في تطبيقك

المشكلة باختصار

أغلب التطبيقات بتخزّن التاريخ كنص زي 2026-07-16 15:00 من غير أي إشارة لمنطقة زمنية. الرقم ده لوحده مالوش معنى. 15:00 في القاهرة مش نفس 15:00 في الرياض ولا في لندن. لمّا مستخدم في منطقة تانية يفتح نفس البيانات، تطبيقك بيخمّن المنطقة غلط، فالموعد بيتزحلق ساعة أو اتنين.

المفهوم بمثال بسيط

تخيّل إنك اتفقت مع صاحبك على مكالمة وقلتله "نتكلم الساعة 8". انت في القاهرة وهو في لندن. لو كل واحد فهم "8 بتوقيت بلده"، هتقعد تستنى ساعتين وهو نايم. الحل إنكم تتفقوا على مرجع واحد ثابت للكل: "نتكلم الساعة 8 بتوقيت جرينتش". كل واحد يحوّلها لتوقيت بلده بنفسه وقت المكالمة بس.

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

الشرح العلمي الدقيق

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

المناطق الزمنية نفسها مش ثابتة. كتير من الدول بتقدّم الساعة ساعة في الصيف وترجّعها في الشتا، وده اللي اسمه التوقيت الصيفي (DST). ده معناه إن الفرق بين بلدك والـ UTC ممكن يتغيّر مرتين في السنة. عشان كده فيه قاعدة بيانات رسمية اسمها IANA Time Zone Database بتسجّل كل التغييرات دي لكل منطقة، وأي لغة محترمة بتعتمد عليها بدل ما تحسب الفرق بنفسها.

الحل: خطوات عملية

1. خزّن كل الأوقات في قاعدة البيانات بالـ UTC، ومعاها المنطقة الزمنية دايمًا.
2. استقبل من المستخدم منطقته الزمنية باسمها (زي Africa/Cairo)، مش بفرق الساعات، عشان التوقيت الصيفي يتحسب صح.
3. حوّل من UTC لتوقيت المستخدم في لحظة العرض بس، مش قبل كده.
4. لو بتبعت الوقت بين أنظمة، استخدم صيغة ISO 8601 اللي بتشيل المنطقة جواها زي 2026-07-16T13:00:00Z.

الكود ده بيوريك الفرق بين الطريقة الغلط والصح في بايثون (نسخة 3.9 أو أحدث):

from datetime import datetime, timezone
from zoneinfo import ZoneInfo  # مدمج في بايثون 3.9+

# غلط: وقت بدون منطقة زمنية (naive) — غامض
naive = datetime(2026, 7, 16, 15, 0)
print(naive)  # 2026-07-16 15:00:00  --> 15:00 فين بالظبط؟ محدش عارف

# صح: خزّن اللحظة بالـ UTC (aware)
utc_time = datetime(2026, 7, 16, 13, 0, tzinfo=timezone.utc)

# اعرض حسب منطقة كل مستخدم وقت العرض بس
cairo  = utc_time.astimezone(ZoneInfo("Africa/Cairo"))
riyadh = utc_time.astimezone(ZoneInfo("Asia/Riyadh"))
london = utc_time.astimezone(ZoneInfo("Europe/London"))

print("القاهرة:", cairo.strftime("%H:%M"))   # 16:00
print("الرياض:",  riyadh.strftime("%H:%M"))  # 16:00
print("لندن:",    london.strftime("%H:%M"))  # 14:00

لاحظ إن نفس اللحظة الواحدة ظهرت بثلاث قيم مختلفة، وكل واحدة صح في بلدها. ده اللي بيحصل فعلاً لمّا تخزّن UTC وتحوّل وقت العرض.

سيناريو واقعي بأرقام

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

المقايضات (trade-offs)

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

متى لا تستخدم هذه الطريقة

لو بتخزّن تاريخ مجرّد ملوش علاقة بلحظة زمنية، زي تاريخ ميلاد أو تاريخ إجازة رسمية، متحوّلوش لـ UTC. التحويل هنا ممكن يزحلق اليوم لقدام أو لورا. خزّنه كتاريخ عادي (date) من غير وقت ولا منطقة. كمان لو التطبيق كله بيشتغل في منطقة زمنية واحدة ومفيش أي احتمال يخرج منها، الموضوع مايستاهلش تعقيد، بس خلي بالك ده افتراض بيكسر بسهولة أول ما تكبر.

الخطوة التالية

افتح أقرب مكان بتخزّن فيه وقت في مشروعك، وشوف هو naive ولا aware. لو ملقتش منطقة زمنية ملصوقة بالقيمة، ده بالظبط مصدر البق القادم. حوّله يخزّن UTC، وخلّي التحويل لتوقيت المستخدم في طبقة العرض بس.

المصادر

• IANA Time Zone Database (قاعدة بيانات المناطق الزمنية الرسمية): iana.org/time-zones
• توثيق بايثون الرسمي لوحدة zoneinfo: docs.python.org/3/library/zoneinfo
• توثيق بايثون الرسمي لوحدة datetime (naive vs aware): docs.python.org/3/library/datetime
• معيار ISO 8601 وصيغة RFC 3339 لتبادل التاريخ والوقت: rfc-editor.org/rfc/rfc3339
• توثيق MDN لكائن Date في جافاسكريبت: developer.mozilla.org — Date