Scroll to navigation

tzfile(5) File Formats Manual tzfile(5)

الاسم

tzfile - معلومات المنطقة الزمنية

الوصف

توجد ملفات معلومات المنطقة الزمنية التي تستخدمها tzset(3) عادةً تحت دليل باسم مثل /usr/share/zoneinfo. تستخدم هذه الملفات التنسيق الموصوف في معيار الإنترنت RFC 9636. كل ملف هو تسلسل من البايتات المكونة من 8 بت. في الملف، يُُمثَّل العدد الصحيح الثنائي بتسلسل من بايت واحد أو أكثر بترتيب الشبكة (bigendian، أو البايت ذو الرتبة العليا أولاً)، مع كون جميع البتات ذات دلالة، ويُمثَّل العدد الصحيح الثنائي الموقَّع باستخدام متمم الاثنين، ويُمثَّل البولياني بعدد صحيح ثنائي من بايت واحد يكون إما 0 (خطأ) أو 1 (صواب). يبدأ التنسيق بترويسة من 44 بايت تحتوي على الحقول التالية:

  • تسلسل ASCII السحري المكون من أربعة بايتات “TZif” يُعرِّف الملف كملف معلومات منطقة زمنية.
  • بايت يُعرِّف إصدار تنسيق الملف (اعتبارًا من 2021، إما ASCII NUL، “2”, “3”, أو “4”).
  • خمسة عشر بايتًا تحتوي على أصفار محجوزة للاستخدام المستقبلي.
  • ست قيم صحيحة مكونة من أربعة بايتات، بالترتيب التالي:
عدد مؤشرات التوقيت العالمي (UT)/المحلي المخزنة في الملف. (UT هو التوقيت العالمي المنسق.)
عدد مؤشرات التوقيت القياسي/الجداري المخزنة في الملف.
عدد الثواني الكبيسة التي تُخزَّن لها إدخالات بيانات في الملف.
عدد أوقات الانتقال التي تُخزَّن لها إدخالات بيانات في الملف.
عدد أنواع التوقيت المحلي التي تُخزَّن لها إدخالات بيانات في الملف (يجب ألا يكون صفرًا).
عدد بايتات سلاسل اختصارات المنطقة الزمنية المخزنة في الملف.

تلي الترويسة أعلاه الحقول التالية، التي تعتمد أطوالها على محتويات الترويسة:

  • قيم صحيحة موقَّعة مكونة من أربعة بايتات tzh_timecnt مرتبة ترتيبًا تصاعديًا. تُكتب هذه القيم بترتيب بايت الشبكة. تُستخدم كل منها كوقت انتقال (كما تعيده time(2)) تتغير عنده قواعد حساب التوقيت المحلي.
  • قيم صحيحة غير موقَّعة مكونة من بايت واحد tzh_timecnt؛ كل منها -باستثناء الأخير- يخبر بأي من الأنواع المختلفة لأنواع التوقيت المحلي الموصوفة في الملف يرتبط بالفترة الزمنية التي تبدأ بوقت الانتقال ذي الفهرس نفسه وتستمر حتى وقت الانتقال التالي (دون تضمينه). (نوع التوقيت الأخير موجود فقط للتحقق من الاتساق مع سلسلة TZ الاستباقية الموصوفة أدناه.) تعمل هذه القيم كفهارس في الحقل التالي.
  • إدخالات ttinfo بعدد tzh_typecnt، يُعرَّف كل منها كما يلي: 

    struct ttinfo {
	int32_t	tt_utoff;
	unsigned char	tt_isdst;
	unsigned char	tt_desigidx;
};

    تُكتب كل بنية كقيمة صحيحة موقَّعة مكونة من أربعة بايتات لـ tt_utoff، بترتيب بايت الشبكة، متبوعة بقيمة بوليانية من بايت واحد لـ tt_isdst وقيمة من بايت واحد لـ tt_desigidx. في كل بنية، تعطي tt_utoff عدد الثواني التي ستُضاف إلى التوقيت العالمي، وتخبر tt_isdst عما إذا كان يجب تعيين tm_isdst بواسطة localtime(3)، وتعمل tt_desigidx كفهرس في مصفوفة بايتات اختصار المنطقة الزمنية التي تلي إدخالات ttinfo في الملف؛ إذا كانت السلسلة المحددة هي "-00"، فإن إدخال ttinfo هو عنصر نائب يشير إلى أن التوقيت المحلي غير محدد. لا تساوي قيمة tt_utoff أبدًا -2**31، للسماح للعملاء ذوي الـ 32 بت بنفيها دون فيضان. أيضًا، في التطبيقات الواقعية تكون tt_utoff في النطاق [-89999, 93599] (أي أكثر من -25 ساعة وأقل من 26 ساعة)؛ وهذا يسمح بدعم سهل من قبل التنفيذات التي تدعم بالفعل النطاق المطلوب بواسطة POSIX وهو [-24:59:59, 25:59:59].

  • بايتات tzh_charcnt تمثل تسميات المنطقة الزمنية، وهي سلاسل بايتات منتهية بمحرف فارغ (null)، كل منها مفهرس بواسطة قيم tt_desigidx المذكورة أعلاه، وكل منها يقابل اختصار منطقة زمنية. يمكن أن تتداخل سلاسل البايتات إذا كانت إحداها لاحقة للأخرى. ترميز هذه السلاسل غير محدد.
  • أزواج tzh_leapcnt من قيم مكونة من أربعة بايتات، مكتوبة بترتيب بايت الشبكة؛ تعطي القيمة الأولى من كل زوج الوقت غير السالب (كما تعيده time(2)) الذي تحدث عنده ثانية كبيسة أو الذي تنتهي عنده صلاحية جدول الثواني الكبيسة؛ الثانية هي عدد صحيح موقَّع يحدد التصحيح، وهو العدد الإجمالي للثواني الكبيسة التي ستُطبق خلال الفترة الزمنية التي تبدأ في الوقت المحدد. أزواج القيم مرتبة ترتيبًا تصاعديًا صارمًا حسب الوقت. يدل كل زوج على ثانية كبيسة واحدة، سواء كانت موجبة أو سالبة، باستثناء أنه إذا كان للزوج الأخير نفس تصحيح الزوج السابق، فإن الزوج الأخير يدل على وقت انتهاء صلاحية جدول الثواني الكبيسة. تقع كل ثانية كبيسة في نهاية شهر تقويمي من التوقيت العالمي المنسق. للثانية الكبيسة الأولى وقت وقوع غير سالب، وتكون ثانية كبيسة موجبة إذا وفقط إذا كان تصحيحها موجبًا؛ يختلف تصحيح كل ثانية كبيسة بعد الأولى عن الثانية الكبيسة السابقة إما بـ 1 لثانية كبيسة موجبة، أو بـ -1 لثانية كبيسة سالبة. إذا كان جدول الثواني الكبيسة فارغًا، يكون تصحيح الثواني الكبيسة صفرًا لجميع الطوابع الزمنية؛ وإلا، بالنسبة للطوابع الزمنية التي تسبق وقت الوقوع الأول، يكون تصحيح الثواني الكبيسة صفرًا إذا كان تصحيح الزوج الأول هو 1 أو -1، وغير محدد بخلاف ذلك (وهو ما لا يمكن أن يحدث إلا في الملفات المقتطعة في البداية).
  • مؤشرات tzh_ttisstdcnt قياسي/جداري، كل منها مخزن كبولياني من بايت واحد؛ تخبر عما إذا كانت أوقات الانتقال المرتبطة بأنواع التوقيت المحلي قد حُدِّدت كتوقيت قياسي أو توقيت محلي (ساعة جدارية).
  • مؤشرات tzh_ttisutcnt توقيت عالمي/محلي، كل منها مخزن كبولياني من بايت واحد؛ تخبر عما إذا كانت أوقات الانتقال المرتبطة بأنواع التوقيت المحلي قد حُدِّدت كتوقيت عالمي أو توقيت محلي. إذا ضُبط مؤشر توقيت عالمي/محلي، فيجب أيضًا ضبط مؤشر قياسي/جداري المقابل.

صُممت مؤشرات قياسي/جداري وتوقيت عالمي/محلي لتحويل أوقات انتقال ملف TZif إلى انتقالات مناسبة لمنطقة زمنية أخرى محددة عبر سلسلة TZ استباقية تفتقر إلى القواعد. على سبيل المثال، عندما يكون TZ="EET-2EEST" ولا يوجد ملف TZif باسم "EET-2EEST"، كانت الفكرة هي تكييف أوقات الانتقال من ملف TZif بالاسم المعروف "posixrules" الذي كان موجودًا لهذا الغرض فقط وكان نسخة من الملف "Europe/Brussels"، وهو ملف ذو إزاحة توقيت عالمي مختلفة. لا تحدد POSIX تفاصيل سلوك التحويل القديم هذا، والقواعد المبدئية تعتمد على التثبيت، ولا يُعرف أي تنفيذ يدعم هذه الميزة للطوابع الزمنية بعد عام 2037، لذا يجب على المستخدمين الذين يرغبون في (على سبيل المثال) التوقيت اليوناني تحديد TZ="Europe/Athens" بدلاً من ذلك لتغطية تاريخية أفضل، مع الرجوع إلى TZ="EET-2EEST,M3.5.0/3,M10.5.0/4" إذا كان الالتزام بـ POSIX.1-2017 أو ما قبله مطلوبًا ولا يلزم التعامل مع الطوابع الزمنية القديمة بدقة.

تستخدم دالة localtime(3) عادةً أول بنية ttinfo في الملف إذا كان tzh_timecnt صفرًا أو كانت وسيطة الوقت أقل من أول وقت انتقال مسجل في الملف.

ملاحظات

توثق صفحة الدليل هذه <tzfile.h> في أرشيف مصدري glibc، انظر timezone/tzfile.h.

يبدو أن timezone(3) تستخدم tzfile داخلياً، لكن glibc ترفض كشفها لمساحة المستخدم. من المرجح أن هذا بسبب أن الدوال الموحدة أكثر فائدة وقابلية للنقل، وموثقة فعلياً من قبل glibc. قد تكون موجودة في glibc فقط لدعم بيانات المنطقة الزمنية غير المدارة من قبل glibc (والتي تُدار من قبل كيان آخر).

تنسيق الإصدار 2

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

إذا لم تكن فارغة، فيجب أن تتوافق سلسلة TZ مع نوع التوقيت المحلي بعد آخر وقت انتقال إذا كان موجودًا في بيانات الثمانية بايتات؛ على سبيل المثال، بالنظر إلى السلسلة “WET0WEST,M3.5.0/1,M10.5.0” ثم إذا كان وقت الانتقال الأخير في يوليو، فيجب أن يحدد نوع التوقيت المحلي للانتقال توقيتًا صيفيًا باختصار “WEST” الذي يسبق التوقيت العالمي بساعة واحدة شرقًا.

يمكن أن تحتوي سلسلة TZ على اختصارات مناطق زمنية وإزاحات التوقيت العالمي التي لا تظهر في أي مكان آخر في ملف TZif.

أيضًا، إذا كان هناك انتقال واحد على الأقل، فيرتبط نوع التوقيت 0 بالفترة الزمنية من الماضي غير المحدد حتى وقت الانتقال الأبكر (دون تضمينه).

تنسيق الإصدار 3

بالنسبة لملفات المنطقة الزمنية بتنسيق الإصدار 3، قد تستخدم سلسلة TZ (انظر newtzset(3)) امتدادات POSIX.1-2024 التالية إلى POSIX.1-2017: أولاً، كما في TZ="<-02>2<-01>,M3.5.0/-1,M10.5.0/0"، قد تكون أجزاء الساعات من أوقات انتقالاتها موقَّعة وتتراوح من -167 إلى 167 بدلاً من الاقتصار على قيم غير موقَّعة من 0 إلى 24. ثانيًا، كما في TZ="XXX3EDT4,0/0,J365/23"، يكون التوقيت الصيفي ساريًا طوال العام إذا بدأ في 1 يناير عند 00:00 وانتهى في 31 ديسمبر عند 24:00 زائد الفرق بين التوقيت الصيفي والتوقيت القياسي.

تنسيق الإصدار 4

بالنسبة لملفات TZif بتنسيق الإصدار 4، يمكن أن يحتوي سجل الثواني الكبيسة الأول على تصحيح ليس +1 ولا -1، لتمثيل اقتطاع ملف TZif في البداية. أيضًا، إذا وُجد انتقالان أو أكثر للثواني الكبيسة وكان تصحيح الإدخال الأخير يساوي الإدخال السابق، فإن الإدخال الأخير يدل على انتهاء صلاحية جدول الثواني الكبيسة بدلاً من ثانية كبيسة؛ الطوابع الزمنية بعد هذا الانتهاء غير موثوقة من حيث أن الإصدارات المستقبلية ستضيف على الأرجح إدخالات ثوانٍ كبيسة بعد الانتهاء، وستغير الثواني الكبيسة المضافة كيفية التعامل مع الطوابع الزمنية لما بعد الانتهاء.

اعتبارات التوافقية

قد تُلحق التغييرات المستقبلية في التنسيق المزيد من البيانات.

تُعتبر ملفات الإصدار 1 تنسيقًا قديمًا ولا ينبغي إنشاؤها، لأنها لا تدعم أوقات الانتقال بعد عام 2038. يجب على القارئات التي تفهم الإصدار 1 فقط تجاهل أي بيانات تمتد إلى ما بعد النهاية المحسوبة لكتلة بيانات الإصدار 1.

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

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

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

ينبغي أن تتكون اختصارات المنطقة الزمنية من ثلاثة (3) رموز ASCII على الأقل ولا تزيد عن ستة (6) من مجموعة الرموز الأبجدية الرقمية، “-”, و “+”. هذا من أجل التوافق مع متطلبات POSIX لاختصارات المنطقة الزمنية.

ينبغي أن يطابق اختصار المنطقة الزمنية الرقمي إزاحة UT. على سبيل المثال، ينبغي استخدام "+0530" فقط إذا كانت إزاحة UT تسبق UT بـ 5.5 ساعة، وينبغي استخدام "-00" فقط إذا كانت إزاحة UT تساوي صفراً.

عند قراءة ملف من الإصدار 2 أو أعلى، ينبغي على القارئات تجاهل ترويسة وكتلة بيانات الإصدار 1 إلا لغرض تخطيها.

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

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

مشكلات التوافقية الشائعة

يوثق هذا القسم المشكلات الشائعة في قراءة أو كتابة ملفات TZif. معظم هذه المشكلات تكمن في توليد ملفات TZif لاستخدامها من قبل القارئات الأقدم. تهدف هذه الأهداف من هذا القسم إلى المساعدة في:

  • أن تُخرِج كاتبات TZif ملفات تتجنب المزالق الشائعة في قارئات TZif الأقدم أو التي تحتوي على علل،
  • أن تتجنب قارئات TZif المزالق الشائعة عند قراءة ملفات مُوَلَّدة بواسطة كاتبات TZif مستقبلية، و
  • أن يرى أي مؤلفين للمواصفات المستقبلية نوع المشكلات التي تظهر عند تغيير تنسيق TZif.

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

تشمل مشكلات التوافقية مع TZif ما يلي:

  • بعض القارئات تفحص بيانات الإصدار 1 فقط. كحل بديل جزئي، يمكن للكاتبة إخراج أكبر قدر ممكن من بيانات الإصدار 1. ومع ذلك، ينبغي على القارئة تجاهل بيانات الإصدار 1، واستخدام بيانات الإصدار 2 فما فوق حتى لو كانت الطوابع الزمنية الأصلية للقارئة تحتوي على 32 بت فقط.
  • قد تسيء بعض القارئات المصممة للإصدار 2 التعامل مع الطوابع الزمنية بعد الانتقال الأخير لملف من الإصدار 3 أو أعلى، لأنها لا تستطيع تحليل توسعات POSIX.1-2024 المضافة إلى POSIX.1-2017 في سلسلة TZ الاستباقية. كحل بديل جزئي، يمكن للكاتبة إخراج انتقالات أكثر من اللازم، بحيث لا تُساء معاملة سوى الطوابع الزمنية في المستقبل البعيد بواسطة قارئات الإصدار 2.
  • قد تسيء بعض القارئات التعامل مع الطوابع الزمنية بعد الانتقال الأخير للملف، لأنها تتطلب وجود كافة الاختصارات أو إزاحات UT الواردة في سلسلة TZ الاستباقية في مكان ما ضمن جداول تسميات المنطقة الزمنية وسجلات نوع الوقت المحلي في الملف. كحل بديل، يمكن للكاتبة إخراج انتقالات أكثر من اللازم، بحيث تحتوي الجداول الأخرى على نسخ مكررة من اختصارات وإزاحات سلسلة TZ الاستباقية.
  • بعض القارئات المصممة للإصدار 2 لا تدعم التوقيت الصيفي الدائم مع انتقالات بعد الساعة 24:00 – على سبيل المثال، سلسلة TZ “EST5EDT,0/0,J365/25” التي تشير إلى التوقيت الصيفي الشرقي الدائم (-04). كحل بديل، يمكن للكاتبة استبدال التوقيت القياسي لمنطقتين زمنيتين شرقاً، على سبيل المثال، “XXX3EDT4,0/0,J365/23” لمنطقة زمنية ذات توقيت قياسي غير مستخدم أبداً (XXX, -03) وتوقيت صيفي سالب (EDT, -04) طوال العام. كبديل، كحل بديل جزئي، يمكن للكاتبة استبدال التوقيت القياسي للمنطقة الزمنية التالية شرقاً – على سبيل المثال، “AST4” لتوقيت أطلنطي قياسي دائم (-04).
  • بعض القارئات المصممة للإصدار 2 أو 3 والتي تتطلب توافقاً صارماً مع RFC 9636 ترفض ملفات الإصدار 4 التي تكون جداول الثواني الكبيسة فيها مبتورة عند البداية أو النهاية في أوقات انتهاء الصلاحية.
  • بعض القارئات تتجاهل التذييل، وتتنبأ بدلاً من ذلك بالطوابع الزمنية المستقبلية من نوع وقت آخر انتقال. كحل بديل جزئي، يمكن للكاتبة إخراج انتقالات أكثر من اللازم.
  • بعض القارئات المبسَّطة تتجاهل كل شيء باستثناء التذييل، وتستخدم سلسلة TZ الاستباقية الخاصة به لحساب جميع الطوابع الزمنية. على الرغم من أن هذا النهج يعمل غالباً للطوابع الزمنية الحالية والمستقبلية، إلا أنه يعاني بوضوح من مشكلات مع الطوابع الزمنية الماضية، وحتى بالنسبة للطوابع الزمنية الحالية فقد يفشل مع إعدادات مثل TZ="Africa/Casablanca". يتوافق هذا مع ملف TZif يحتوي على انتقالات صريحة حتى عام 2087، متبوعة بتذييل يحتوي على سلسلة TZ “<+01>-1”, التي ينبغي استخدامها فقط للطوابع الزمنية بعد آخر انتقال صريح.
  • بعض القارئات لا تستخدم نوع الوقت 0 للطوابع الزمنية قبل الانتقال الأول، حيث تستنتج نوع وقت باستخدام استدلال لا يختار دائماً نوع الوقت 0. كحل بديل جزئي، يمكن للكاتبة إخراج انتقال أول وهمي (لا يقوم بأي عملية) في وقت مبكر.
  • بعض القارئات تسيء التعامل مع الطوابع الزمنية قبل الانتقال الأول الذي له طابع زمني ليس أقل من -2**31. القارئات التي تدعم الطوابع الزمنية 32-بت فقط تكون أكثر عرضة لهذه المشكلة، على سبيل المثال، عند معالجة انتقالات 64-بت لا يمكن تمثيل بعضها في 32 بت. كحل بديل جزئي، يمكن للكاتبة إخراج انتقال وهمي عند الطابع الزمني -2**31.
  • بعض القارئات تسيء التعامل مع الانتقال إذا كان طابعه الزمني يملك أصغر قيمة ممكنة لعدد صحيح 64-بت ذو إشارة. لا يُنصح بالطوابع الزمنية الأقل من -2**59.
  • بعض القارئات تسيء التعامل مع سلاسل TZ الاستباقية التي تحتوي على “<” أو “>”. كحل بديل جزئي، يمكن للكاتبة تجنب استخدام “<” أو “>” لاختصارات المنطقة الزمنية التي تحتوي على أحرف أبجدية فقط.
  • الكثير من القارئات تسيء التعامل مع اختصارات المنطقة الزمنية التي تحتوي على رموز ليست من ASCII. لا يُنصح بهذه الرموز.
  • قد تسيء بعض القارئات التعامل مع اختصارات المنطقة الزمنية التي تحتوي على أقل من 3 أو أكثر من 6 رموز أو التي تحتوي على رموز ASCII غير الأبجدية الرقمية، “-”, و “+”. لا يُنصح بهذه الاختصارات.
  • بعض القارئات تسيء التعامل مع ملفات TZif التي تحدد إزاحات UT للتوقيت الصيفي تكون أقل من إزاحات UT للتوقيت القياسي المقابل. لا تدعم هذه القارئات مواقع مثل أيرلندا، التي تستخدم ما يعادل سلسلة TZ “IST-1GMT0,M10.5.0,M3.5.0/1”, التي تراقب التوقيت القياسي (IST, +01) في الصيف والتوقيت الصيفي (GMT, +00) في الشتاء. كحل بديل جزئي، يمكن للكاتبة إخراج بيانات لما يعادل سلسلة TZ “GMT0IST,M3.5.0/1,M10.5.0”, وبالتالي تبديل التوقيت القياسي والتوقيت الصيفي. على الرغم من أن هذا الحل البديل يحدد بشكل خاطئ أي جزء من السنة يستخدم التوقيت الصيفي، إلا أنه يسجل إزاحات UT واختصارات المنطقة الزمنية بشكل صحيح.
  • بعض القارئات تولِّد طوابع زمنية غامضة للثواني الكبيسة الموجبة التي تحدث عندما لا تكون إزاحة UTC من مضاعفات 60 ثانية. على سبيل المثال، مع إزاحة UTC قدرها +01:23:45 وثانية كبيسة موجبة 78796801 (1972-06-30 23:59:60 UTC)، ستقوم بعض القارئات بتعيين كل من 78796800 و 78796801 إلى الساعة 01:23:45 بالتوقيت المحلي في اليوم التالي بدلاً من تعيين الأخيرة إلى 01:23:46، وسوف تقوم بتعيين 78796815 إلى 01:23:59 بدلاً من 01:23:60. لم تكن هذه مشكلة عملية حتى الآن، نظراً لأن أياً من السلطات المدنية لم تلاحظ مثل هذه الإزاحات لـ UTC منذ إدخال الثواني الكبيسة في عام 1972.

بعض مشكلات التوافقية هي علل في القارئات مدرجة هنا غالباً كتحذيرات لمطوري القارئات.

  • بعض القارئات لا تدعم الطوابع الزمنية السالبة. ينبغي على مطوري التطبيقات الموزعة وضع هذا في الاعتبار إذا كانوا بحاجة للتعامل مع بيانات تعود لما قبل عام 1970.
  • تسيء بعض القارئات التعامل مع الطوابع الزمنية قبل أول انتقال له طابع زمني غير سالب. من المرجح أن تكون القارئات التي لا تدعم الطوابع الزمنية السالبة أكثر عرضة لهذه المشكلة.
  • تسيء بعض القارئات التعامل مع اختصارات المنطقة الزمنية مثل “-08” التي تحتوي على “+”, “-”, أو أرقام.
  • تسيء بعض القارئات التعامل مع إزاحات التوقيت العالمي (UT) الخارجة عن النطاق التقليدي من -12 إلى +12 ساعة، وبالتالي فهي لا تدعم مواقع مثل كيريتيماسلي التي تقع خارج هذا النطاق.
  • تسيء بعض القارئات التعامل مع إزاحات التوقيت العالمي (UT) في النطاق [-3599, -1] ثانية من التوقيت العالمي لأنها تقسم الإزاحة قسمة صحيحة على 3600 لتحصل على 0 ثم تعرض جزء الساعة كـ “+00”.
  • تسيء بعض القارئات التعامل مع إزاحات التوقيت العالمي (UT) التي ليست من مضاعفات ساعة واحدة، أو 15 دقيقة، أو دقيقة واحدة.

انظر أيضًا

time(2)، localtime(3)، tzset(3)، tzselect(8)، zdump(8)، zic(8).

Olson A, Eggert P, Murchison K. تنسيق معلومات المنطقة الزمنية (TZif). أكتوبر 2024. Internet RFC 9636 doi:10.17487/RFC9636.

ترجمة

تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.

قاعدة بيانات المناطق الزمنية