قاعدة بيانات المناطق الزمنية IANA (tz): ما هي ولماذا تهم

ما هي قاعدة بيانات المناطق الزمنية IANA في الواقع

إذا سبق لك العمل مع التواريخ والأوقات في البرمجيات، فقد اعتمدت على قاعدة بيانات المناطق الزمنية IANA سواء علمت بذلك أم لا. تُعرف بعدة أسماء — قاعدة بيانات tz، tzdata، قاعدة بيانات أولسون، أو zoneinfo — لكنها جميعًا تشير إلى نفس الشيء: كتالوج تعاوني ومتاح مجانًا للمناطق الزمنية في العالم والقواعد التي تحكمها.

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

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

نبذة تاريخية قصيرة

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

تولى بول إيجرت منصب المحرر الرئيسي ولا يزال المنسق طويل الأمد للمشروع. جعل تجميعه لوثيقة theory.html المصاحبة وسجل الالتزامات الدقيق قاعدة البيانات مرجعًا تاريخيًا بقدر ما هي مرجع تقني.

في عام 2011، بعد نزاع قانوني وجيز ولكنه مقلق بشأن البيانات التاريخية، انتقلت الإشراف إلى هيئة أرقام الإنترنت المخصصة (IANA)، نفس الهيئة التي تنسق موارد الإنترنت الأساسية الأخرى. تنشر IANA الآن الإصدارات الرسمية، ولهذا السبب أصبح "قاعدة بيانات المناطق الزمنية IANA" هو الاسم الرسمي. لا يزال العمل يتم من قبل نفس مجتمع المساهمين؛ توفر IANA موطنًا مؤسسيًا ونقطة توزيع مستقرة.

اصطلاح التسمية: `المنطقة/الموقع`

واحدة من أكثر السمات تميزًا في قاعدة البيانات هي كيفية تسميتها للمناطق. بدلاً من أسماء الدول أو الإزاحات الخام، تستخدم تنسيق المنطقة/الموقع، المرتكز دائمًا تقريبًا على مدينة ممثلة:

America/New_York
Europe/London
Asia/Kolkata
Australia/Sydney

"المنطقة" عادة ما تكون قارة أو محيطًا (America، Europe، Asia، Pacific)، و"الموقع" هو مدينة معروفة داخل المنطقة. يبدو هذا الاختيار غريبًا حتى تفهم المنطق وراءه.

المدن مستقرة؛ الحدود السياسية والإزاحات ليست كذلك. تنقسم الدول، وتندمج، وتغير أسماءها، وتغير ساعاتها. المدينة، على النقيض من ذلك، هي نقطة جغرافية ثابتة لها تاريخ مستمر في ضبط الوقت. تسمية منطقة America/New_York بدلاً من "التوقيت الشرقي للولايات المتحدة" أو "UTC-5" يعني أن المعرف يظل صالحًا حتى مع تطور القواعد المرتبطة به.

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

لماذا الإزاحات الخام غير كافية

الغريزة الشائعة للمبتدئين هي تخزين الوقت كـ "UTC+5:30" واعتبار الأمر منتهيًا. هذا ينجح للحظة واحدة، لكنه ينهار بمجرد أن تحتاج إلى التفكير في الأحداث المستقبلية أو المتكررة، لأن الإزاحات ليست خصائص ثابتة لمكان ما. إنها مخرجات قواعد تغيرها الحكومات باستمرار وفي كثير من الأحيان بشكل مفاجئ.

ضع في اعتبارك بعض الأمثلة الواقعية التي كان على قاعدة البيانات استيعابها:

تخطت ساموا 30 ديسمبر 2011 بالكامل. لمحاذاة يوم عملها مع أستراليا ونيوزيلندا بدلاً من الولايات المتحدة، قفزت ساموا عبر خط التاريخ الدولي، منتقلة من UTC-11 إلى UTC+13. لأي شخص في الجزر، ذلك الجمعة ببساطة لم يكن موجودًا.
تلغي الدول التوقيت الصيفي أو تعتمده أو تعيد جدولته بإشعار قصير. ناقش الاتحاد الأوروبي إنهاء التوقيت الصيفي؛ غيرت العديد من الدول والولايات الأمريكية قواعد التوقيت الصيفي الخاصة بها في العقود الأخيرة. حولت تركيا وروسيا ودول أخرى إزاحاتها القياسية بالكامل.
تواريخ بدء وانتهاء التوقيت الصيفي تتغير. نقلت الولايات المتحدة حدود التوقيت الصيفي في عام 2007. أي نظام قام بترميز القاعدة القديمة بشكل ثابت أنتج أوقاتًا خاطئة بصمت لأسابيع كل عام.

إذا قمت بتخزين إزاحة فقط، فلا يمكنك الإجابة على السؤال "ماذا سيكون الوقت المحلي في سانتياغو في 15 نوفمبر من العام القادم؟" — لأن الإجابة تعتمد على قواعد قد لا تكون قد اكتملت بعد. تخزين معرف المنطقة (America/Santiago) بالإضافة إلى قاعدة البيانات يسمح للبرمجيات بحساب الإزاحة الصحيحة لأي لحظة، ماضية أو مستقبلية، وإعادة حسابها تلقائيًا عندما تتغير القواعد.

هذا هو جوهر القيمة المقترحة: قاعدة بيانات tz تفصل هوية المكان عن القواعد المتغيرة باستمرار التي تحدد ساعته.

كيف تتم الصيانة

تتم الصيانة بشكل علني. التغييرات المقترحة — قاعدة جديدة للتوقيت الصيفي، تاريخ تاريخي مصحح، إعلان حكومي — تتم مناقشتها على القائمة البريدية العامة لـ tz، حيث يستشهد المساهمون بالجريدة الرسمية والتقارير الإخبارية والمراسيم الحكومية كدليل. تؤخذ الدقة على محمل الجد؛ يتم فحص التغييرات التي تطرأ على البيانات التاريخية بشكل خاص مقابل المصادر الأولية.

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

من يعتمد عليها

كل شيء تقريبًا.

أنظمة التشغيل. توزيعات لينكس تشحن tzdata كحزمة أساسية. macOS يستمد بيانات منطقته من نفس المصدر. يستخدم Windows مناطق قائمة على السجل لأسباب قديمة ولكنه يعرض مناطق IANA من خلال مكتبة ICU وواجهات برمجة التطبيقات الحديثة.
لغات البرمجة. كل مكتبة تاريخ/وقت ناضجة تقريبًا تقرأ من قاعدة بيانات tz أو تحزمها: zoneinfo في بايثون، java.time في جافا، مشروع ICU، PostgreSQL، محركات JavaScript عبر ICU، روبي، PHP، وغيرها الكثير.
التطبيقات. التقويمات، أنظمة الحجز، منصات التداول المالي، أدوات تحليل السجلات، وخدمات الجدولة تعتمد عليها جميعًا، عادةً دون أن يفكر مطوروها في الأمر.

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

إذا كنت ترغب في استكشاف المناطق نفسها، تصفح القائمة الكاملة لـ المناطق الزمنية IANA أو شاهد كيف يتم توزيعها عبر العالم في دليلنا لـ جميع المناطق الزمنية.

الأسئلة الشائعة

هل قاعدة بيانات tz هي نفسها tzdata وzoneinfo وقاعدة بيانات أولسون؟

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

كم مرة يتم تحديث قاعدة البيانات؟

لا يوجد جدول زمني ثابت. يتم تحفيز الإصدارات بأحداث من العالم الحقيقي — حكومة تغير قواعد التوقيت الصيفي أو الإزاحة القياسية، أو تصحيح للبيانات التاريخية. بعض السنوات تشهد إصدارًا واحدًا؛ البعض الآخر يشهد عدة إصدارات. كل منها يُسمى مثل 2024a، 2024b، مع زيادة الحرف خلال العام.

لماذا تسمي المناطق بأسماء مدن مثل `America/New_York`؟

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

هل يمكنني فقط تخزين إزاحة UTC بدلاً من اسم المنطقة؟

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

من يدير المشروع الآن؟

يتم نشره بواسطة IANA، التي تولت الإشراف في عام 2011، وينسقه بول إيجرت مع مجتمع من المساهمين يعملون عبر القائمة البريدية العامة لـ tz. يظل العمل الفني جهدًا تعاونيًا يقوده متطوعون.