Scroll to navigation

tzfile(5) File Formats Manual tzfile(5)

الاسم

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

الوصف

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

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

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

  • قيم صحيحة موقَّعة مكونة من أربعة بايتات tzh_timecnt مرتبة ترتيبًا تصاعديًا. تُكتب هذه القيم بترتيب بايت الشبكة. تُستخدم كل منها كوقت انتقال (كما تعيده time(2)) تتغير عنده قواعد حساب التوقيت المحلي.
  • قيم tzh_timecnt كعدد صحيح غير موقَّع من بايت واحد؛ كل واحدة منها عدا الأخيرة تخبر عن أي من أنواع التوقيت المحلي المختلفة الموصوفة في الملف ترتبط بالفترة الزمنية التي تبدأ بزمن الانتقال ذي نفس الفهرس وتستمر حتى، ولكن لا تشمل، زمن الانتقال التالي. (نوع التوقيت الأخير موجود فقط للتحقق من الاتساق مع سلسلة TZ بأسلوب POSIX.1-2017 الموصوفة أدناه.) تعمل هذه القيم كفهارس في الحقل التالي.
  • إدخالات 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 عدد الثواني التي يجب إضافتها إلى التوقيت العالمي (UT)، وتخبر 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)) الذي يحدث فيه ثانية كبيسة أو الذي تنتهي عنده صلاحية جدول الثواني الكبيسة؛ الثانية هي عدد صحيح موقَّع يحدد التصحيح، وهو العدد الإجمالي للثواني الكبيسة المراد تطبيقها خلال الفترة الزمنية التي تبدأ عند الزمن المعطى. تُرتب أزواج القيم ترتيباً تصاعدياً صارماً حسب الزمن. يدل كل زوج على ثانية كبيسة واحدة، إما موجبة أو سالبة، باستثناء أنه إذا كان الزوج الأخير له نفس تصحيح الزوج السابق، فإن الزوج الأخير يدل على زمن انتهاء صلاحية جدول الثواني الكبيسة. كل ثانية كبيسة تكون في نهاية شهر تقويمي بالتوقيت العالمي (UTC). للثانية الكبيسة الأولى زمن حدوث غير سالب، وتكون ثانية كبيسة موجبة إذا وفقط إذا كان تصحيحها موجباً؛ يختلف تصحيح كل ثانية كبيسة بعد الأولى عن الثانية الكبيسة السابقة إما بـ 1 لثانية كبيسة موجبة، أو بـ -1 لثانية كبيسة سالبة. إذا كان جدول الثواني الكبيسة فارغاً، فإن تصحيح الثانية الكبيسة يكون صفراً لكل الطوابع الزمنية؛ وبخلاف ذلك، للطوابع الزمنية قبل زمن الحدوث الأول، يكون تصحيح الثانية الكبيسة صفراً إذا كان تصحيح الزوج الأول هو 1 أو -1، وغير محدد بخلاف ذلك (وهو ما يمكن أن يحدث فقط في الملفات المبتورة في البداية).
  • مؤشرات tzh_ttisstdcnt قياسي/جداري، كل منها مخزن كبولياني من بايت واحد؛ تخبر عما إذا كانت أوقات الانتقال المرتبطة بأنواع التوقيت المحلي قد حُدِّدت كتوقيت قياسي أو توقيت محلي (ساعة جدارية).
  • مؤشرات tzh_ttisutcnt توقيت عالمي/محلي، كل منها مخزن كبولياني من بايت واحد؛ تخبر عما إذا كانت أوقات الانتقال المرتبطة بأنواع التوقيت المحلي قد حُدِّدت كتوقيت عالمي أو توقيت محلي. إذا ضُبط مؤشر توقيت عالمي/محلي، فيجب أيضًا ضبط مؤشر قياسي/جداري المقابل.

صُممت مؤشرات التوقيت القياسي/الجداري والتوقيت العالمي/المحلي لتحويل أزمنة انتقال ملف TZif إلى انتقالات مناسبة لمنطقة زمنية أخرى محددة عبر سلسلة TZ بأسلوب POSIX.1-2017 تفتقر إلى القواعد. على سبيل المثال، عندما تكون 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 مطلوباً ولم تكن هناك حاجة للتعامل مع الطوابع الزمنية الأقدم بدقة.

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

ملاحظات

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

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

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

بالنسبة لملفات المنطقة الزمنية بتنسيق الإصدار 2، تتبع الترويسة والبيانات أعلاه ترويسة وبيانات ثانية، متطابقة في التنسيق باستثناء استخدام ثمانية بايتات لكل زمن انتقال أو زمن ثانية كبيسة. (تظل أعداد الثواني الكبيسة أربعة بايتات.) بعد الترويسة والبيانات الثانية تأتي سلسلة محصورة بسطر جديد بأسلوب محتويات متغير البيئة TZ لـ POSIX.1-2017، للاستخدام في التعامل مع اللحظات بعد آخر زمن انتقال مخزن في الملف أو لكل اللحظات إذا لم يكن للملف أي انتقالات. سلسلة TZ تكون فارغة (أي لا يوجد شيء بين السطور الجديدة) إذا لم يكن هناك تمثيل بأسلوب POSIX.1-2017 لتلك اللحظات. إذا كانت غير فارغة، يجب أن تتفق سلسلة TZ مع نوع التوقيت المحلي بعد آخر زمن انتقال إذا كان موجوداً في بيانات الثمانية بايتات؛ على سبيل المثال، بالنظر إلى السلسلة “WET0WEST,M3.5.0/1,M10.5.0” ثم إذا كان وقت الانتقال الأخير في يوليو، فيجب أن يحدد نوع التوقيت المحلي للانتقال توقيتًا صيفيًا باختصار “WEST” التي تسبق التوقيت العالمي (UT) بساعة واحدة. أيضًا، إذا كان هناك انتقال واحد على الأقل، يرتبط نوع التوقيت 0 بالفترة الزمنية من الماضي غير المحدد حتى، ولكن لا يشمل، زمن الانتقال الأبكر.

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

بالنسبة لملفات المنطقة الزمنية بتنسيق الإصدار 3، قد تستخدم سلسلة TZ امتدادين طفيفين لتنسيق TZ لـ POSIX.1-2017، كما هو موصوف في newtzset(3). أولاً، قد يكون جزء الساعات من أزمنة انتقالها موقَّعاً ويتراوح من -167 إلى 167 بدلاً من القيم غير الموقَّعة المطلوبة في POSIX من 0 إلى 24. ثانياً، يكون التوقيت الصيفي سارياً طوال العام إذا بدأ في 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) أحرف على الأقل ولا تزيد عن ستة (6) أحرف ASCII من مجموعة الأبجدية الرقمية، “-”, و “+”. هذا من أجل التوافق مع متطلبات POSIX لاختصارات المنطقة الزمنية.

عند قراءة ملف من الإصدار 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-2017 في السلسلة الشبيهة بـ TZ. كحل جزئي، يمكن للكاتب إخراج انتقالات أكثر مما هو ضروري، بحيث لا تُساء معاملة سوى الطوابع الزمنية في المستقبل البعيد من قبل قارئات الإصدار 2.
  • بعض القارئات المصممة للإصدار 2 لا تدعم التوقيت الصيفي الدائم مع انتقالات بعد الساعة 24:00 – على سبيل المثال، سلسلة TZ “EST5EDT,0/0,J365/25” التي تشير إلى التوقيت الصيفي الشرقي الدائم (-04). كحل بديل، يمكن للكاتبة استبدال التوقيت القياسي لمنطقتين زمنيتين شرقاً، على سبيل المثال، “XXX3EDT4,0/0,J365/23” لمنطقة زمنية ذات توقيت قياسي غير مستخدم أبداً (XXX, -03) وتوقيت صيفي سالب (EDT, -04) طوال العام. كبديل، كحل بديل جزئي، يمكن للكاتبة استبدال التوقيت القياسي للمنطقة الزمنية التالية شرقاً – على سبيل المثال، “AST4” لتوقيت أطلنطي قياسي دائم (-04).
  • بعض القارئات المصممة للإصدار 2 أو 3، والتي تتطلب توافقاً صارماً مع RFC 8536، ترفض ملفات الإصدار 4 التي تكون جداول ثوانيها الكبيسة مبتورة في البداية أو التي تنتهي بأزمنة انتهاء الصلاحية.
  • بعض القارئات تتجاهل التذييل، وتتنبأ بدلاً من ذلك بالطوابع الزمنية المستقبلية من نوع وقت آخر انتقال. كحل بديل جزئي، يمكن للكاتبة إخراج انتقالات أكثر من اللازم.
  • بعض القارئات لا تستخدم نوع الوقت 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 ثانية. على سبيل المثال، في منطقة زمنية بإزاحة توقيت عالمي +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. لم تكن هذه مشكلة عملية حتى الآن، حيث لم تلاحظ أي سلطة مدنية مثل هذه الإزاحات في التوقيت العالمي منذ إدخال الثواني الكبيسة في عام 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). فبراير 2019. Internet RFC 8536 doi:10.17487/RFC8536.

ترجمة

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

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

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

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