tzfile(5) File Formats Manual tzfile(5)

tzfile - اطلاعات مربوط به منطقه زمانی (تایمزون)

پرونده‌های اطلاعات منطقه زمانی (timezone) که توسط tzset(3) استفاده می‌شوند، معمولاً در پوشه‌ای با نامی شبیه به /usr/share/zoneinfo یافت می‌شوند. این پرونده‌ها از قالبی استفاده می‌کنند که در RFC 9636 اینترنت توصیف شده است. هر پرونده دنباله‌ای از بایت‌های ۸ بیتی است. در یک پرونده، یک عدد صحیح دودویی با دنباله‌ای از یک یا چند بایت با ترتیب بایت شبکه (big-endian، یا ابتدا بایت با مرتبه بالا)، با ارزش بودن تمامی بیت‌ها نمایش داده می‌شود، یک عدد صحیح دودویی علامت‌دار با استفاده از مکمل دو (two's complement) نمایش می‌یابد، و یک متغیر بولی با یک عدد صحیح دودویی یک‌بایتی نمایش داده می‌شود که یا ۰ (نادرست) یا ۱ (درست) است. این قالب با یک سربرگ ۴۴ بایتی شامل فیلدهای زیر آغاز می‌شود:

  • دنباله چهار بایتی اسکی (ASCII) جادویی “TZif” که پرونده را به عنوان یک پرونده حاوی اطلاعات منطقه زمانی مشخص می‌کند.
  • یک بایت که نسخه قالب پرونده را تعیین می‌کند (تا سال ۲۰۲۱، یا یک NUL اسکی، “2”، “3”، یا “4”).
  • پانزده بایت حاوی صفر که برای استفاده در آینده رزرو شده‌اند.
  • شش مقدار عدد صحیح چهار بایتی، با ترتیب زیر:
تعداد نشانگرهای UT/محلی ذخیره‌شده در پرونده. (UT همان زمان جهانی یا Universal Time است.)
تعداد نشانگرهای استاندارد/ساعت دیواری ذخیره‌شده در پرونده.
تعداد ثانیه‌های کبیسه‌ای که ورودی‌های داده آن‌ها در پرونده ذخیره شده است.
تعداد زمان‌های گذار که ورودی‌های داده آن‌ها در پرونده ذخیره شده است.
تعداد انواع زمان محلی که ورودی‌های داده آن‌ها در پرونده ذخیره شده است (نباید صفر باشد).
تعداد بایت‌های رشته‌های اختصاری منطقه زمانی ذخیره‌شده در پرونده.

پس از سربرگ فوق، فیلدهای زیر قرار دارند که طول آن‌ها به محتویات سربرگ بستگی دارد:

  • به تعداد tzh_timecnt مقدار عدد صحیح علامت‌دار چهار بایتی که به ترتیب صعودی مرتب شده‌اند. این مقادیر با ترتیب بایت شبکه نوشته می‌شوند. هر یک به عنوان یک زمان گذار (همان‌طور که توسط time(2) برگردانده می‌شود) استفاده می‌شود که در آن قواعد محاسبه زمان محلی تغییر می‌کند.
  • به تعداد tzh_timecnt مقدار عدد صحیح بدون علامت یک‌بایتی؛ هر یک به جز آخرین مورد، مشخص می‌کند کدام‌یک از انواع گوناگون زمان محلی توصیف‌شده در پرونده، با بازه زمانی مرتبط است که از زمان گذار با همان شاخص آغاز می‌شود و تا قبل از زمان گذار بعدی (بدون شامل شدن خود آن) ادامه می‌یابد. (آخرین نوع زمان فقط برای بررسی سازگاری با رشته پیش‌بینانه TZ که در زیر توضیح داده شده، حضور دارد.) این مقادیر به عنوان شاخص‌هایی به فیلد بعدی به کار می‌روند.
  • به تعداد tzh_typecnt ورودی ttinfo، که هر کدام به صورت زیر تعریف می‌شوند: 
    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 نخواهد بود، تا به کلاینت‌های ۳۲ بیتی امکان دهد آن را بدون سرریز منفی کنند. همچنین، در کاربردهای واقعی tt_utoff در محدوده [-89999, 93599] قرار دارد (یعنی بیش از -25 ساعت و کمتر از 26 ساعت)؛ این امر پشتیبانی آسان توسط پیاده‌سازی‌هایی را ممکن می‌سازد که از پیش از محدوده مورد نیاز POSIX یعنی [-24:59:59, 25:59:59] پشتیبانی می‌کنند.

  • به تعداد tzh_charcnt بایت که نام‌گذاری‌های منطقه زمانی را نمایش می‌دهند، که رشته‌های بایتی با پایان صفر (null-terminated) هستند که هر یک با مقادیر tt_desigidx مذکور در بالا اندیس‌گذاری می‌شوند و هر یک متناظر با یک نام اختصاری منطقه زمانی است. اگر یکی از رشته‌های بایتی پسوندی از دیگری باشد، این رشته‌ها می‌توانند هم‌پوشانی داشته باشند. کدگذاری این رشته‌ها مشخص نشده است.
  • به تعداد tzh_leapcnt جفت‌مقدار چهار بایتی، نوشته‌شده با ترتیب بایت شبکه؛ نخستین مقدار از هر جفت، زمان غیرمنفی (همان‌طور که توسط time(2) برگردانده می‌شود) را مشخص می‌کند که در آن ثانیه کبیسه رخ می‌دهد یا جدول ثانیه کبیسه منقضی می‌شود؛ مقدار دوم یک عدد صحیح علامت‌دار است که مقدار تصحیح را تعیین می‌کند، یعنی کل تعداد ثانیه‌های کبیسه‌ای که باید در طول بازه زمانی آغازشده از زمان داده‌شده اعمال گردند. جفت‌مقادیر به ترتیب اکیداً صعودی بر اساس زمان مرتب شده‌اند. هر جفت نشان‌دهنده یک ثانیه کبیسه (مثبت یا منفی) است، به جز این‌که اگر آخرین جفت دارای همان تصحیح جفت قبلی باشد، آخرین جفت نشان‌دهنده زمان انقضای جدول ثانیه کبیسه خواهد بود. هر ثانیه کبیسه در انتهای یک ماه تقویمی UTC قرار دارد. نخستین ثانیه کبیسه دارای زمان رخداد غیرمنفی است، و یک ثانیه کبیسه مثبت است اگر و تنها اگر مقدار تصحیح آن مثبت باشد؛ مقدار تصحیح برای هر ثانیه کبیسه پس از اولین مورد، با ثانیه کبیسه پیشین به اندازه ۱ برای ثانیه کبیسه مثبت یا -1 برای ثانیه کبیسه منفی تفاوت دارد. اگر جدول ثانیه کبیسه خالی باشد، مقدار تصحیح ثانیه کبیسه برای تمام برچسب‌های زمانی صفر است؛ در غیر این صورت، برای برچسب‌های زمانی پیش از نخستین زمان رخداد، اگر تصحیح جفت نخست ۱ یا -1 باشد، تصحیح ثانیه کبیسه صفر خواهد بود و در غیر این صورت نامشخص است (که تنها در پرونده‌هایی می‌تواند رخ دهد که در آغاز بریده شده‌اند).
  • به تعداد tzh_ttisstdcnt نشانگر استاندارد/ساعت دیواری، که هر یک به صورت یک متغیر بولی یک‌بایتی ذخیره شده‌اند؛ آن‌ها مشخص می‌کنند که آیا زمان‌های گذار مرتبط با انواع زمان محلی به صورت زمان استاندارد یا زمان محلی (ساعت دیواری) تعیین شده بودند.
  • به تعداد tzh_ttisutcnt نشانگر UT/محلی، که هر یک به صورت یک متغیر بولی یک‌بایتی ذخیره شده‌اند؛ آن‌ها مشخص می‌کنند که آیا زمان‌های گذار مرتبط با انواع زمان محلی به صورت UT یا زمان محلی تعیین شده بودند. اگر یک نشانگر UT/محلی تنظیم شده باشد، نشانگر متناظر استاندارد/ساعت دیواری نیز باید تنظیم شده باشد.

نشانگرهای استاندارد/ساعت دیواری و UT/محلی برای تبدیل زمان‌های گذار یک پرونده TZif به گذارهای مناسب برای یک منطقه زمانی دیگر طراحی شده بودند که از طریق یک رشته پیش‌بینانه TZ فاقد قانون مشخص می‌شد. برای مثال، هنگامی که TZ="EET-2EEST" است و هیچ پرونده TZif با نام "EET-2EEST" وجود ندارد، ایده این بود که زمان‌های گذار از یک پرونده TZif با نام شناخته‌شده "posixrules" اقتباس شود که صرفاً برای همین منظور حضور داشت و یک رونوشت از پرونده "Europe/Brussels" (پرونده‌ای با اختلاف UT متفاوت) بود. استاندارد POSIX جزئیات این رفتار تبدیلی منسوخ‌شده را تعیین نمی‌کند، قواعد پیش‌فرض وابسته به نحوه نصب هستند و هیچ پیاده‌سازی شناخته‌شده‌ای برای پشتیبانی از این ویژگی برای برچسب‌های زمانی پس از ۲۰۳۷ وجود ندارد؛ بنابراین کاربرانی که (برای نمونه) زمان یونان را می‌خواهند باید برای پوشش تاریخی بهتر به جای آن TZ="Europe/Athens" را تعیین کنند، و در صورتی که انطباق با POSIX.1-2017 یا نسخه‌های پیشین نیاز باشد و نیازی به مدیریت دقیق برچسب‌های زمانی قدیمی‌تر نباشد، به TZ="EET-2EEST,M3.5.0/3,M10.5.0/4" رجوع نمایند.

تابع localtime(3) معمولاً در صورتی که tzh_timecnt صفر باشد یا آرگومان زمان کمتر از نخستین زمان گذار ثبت‌شده در پرونده باشد، از اولین ساختار ttinfo در پرونده استفاده می‌کند.

برای پرونده‌های منطقه زمانی با قالب نسخه ۲، پس از سربرگ و داده‌های فوق، سربرگ و داده دومی قرار می‌گیرد که از نظر قالب کاملاً یکسان هستند، با این تفاوت که برای هر زمان گذار یا زمان ثانیه کبیسه از هشت بایت استفاده می‌شود. (شمارنده‌های ثانیه کبیسه چهار بایتی باقی می‌مانند.) پس از سربرگ و داده‌های دوم، یک رشته محصور در خط جدید (newline) به سبک محتویات یک TZ پیش‌بینانه می‌آید، تا برای رسیدگی به لحظات پس از آخرین زمان گذار ذخیره‌شده در پرونده یا برای تمام لحظات در صورتی که پرونده فاقد گذار باشد، مورد استفاده قرار گیرد. اگر بازنمایی پیش‌بینانه‌ای برای چنین لحظاتی وجود نداشته باشد، رشته TZ خالی است (یعنی هیچ چیزی میان خطوط جدید قرار ندارد).

در صورت خالی نبودن، رشته TZ باید با نوع زمان محلی پس از آخرین زمان گذار (در صورت وجود در داده‌های هشت بایتی) مطابقت داشته باشد؛ برای نمونه، با داشتن رشته “WET0WEST,M3.5.0/1,M10.5.0” اگر آخرین زمان گذار در ماه ژوئیه باشد، نوع زمان محلی آن گذار باید ساعت تابستانی را با نام اختصاری “WEST” مشخص کند که یک ساعت در شرق UT است.

رشته TZ می‌تواند شامل اختصارات منطقه زمانی و اختلافات UT باشد که در هیچ کجای دیگر پرونده TZif ظاهر نشده‌اند.

همچنین، اگر دست‌کم یک گذار وجود داشته باشد، نوع زمان ۰ با بازه زمانی از گذشته نامحدود تا قبل از زودترین زمان گذار (بدون شامل شدن خود آن) مرتبط است.

برای پرونده‌های منطقه زمانی با قالب نسخه ۳، یک رشته TZ (رجوع کنید به newtzset(3)) می‌تواند از افزونه‌های POSIX.1-2024 نسبت به POSIX.1-2017 زیر استفاده کند: نخست، همانند TZ="<-02>2<-01>,M3.5.0/-1,M10.5.0/0" ، بخش ساعتِ زمان‌های گذار آن می‌تواند علامت‌دار باشد و به جای محدود بودن به مقادیر بدون علامت بین ۰ تا ۲۴، در بازه -167 تا 167 قرار گیرد. دوم، همانند TZ="XXX3EDT4,0/0,J365/23" ، در صورتی که ساعت تابستانی در ۱ ژانویه ساعت 00:00 آغاز شود و در ۳۱ دسامبر در ساعت 24:00 به علاوه تفاوت بین ساعت تابستانی و ساعت استاندارد به پایان برسد، ساعت تابستانی (DST) در تمام طول سال اعمال می‌شود.

برای پرونده‌های TZif با قالب نسخه ۴، نخستین رکورد ثانیه کبیسه می‌تواند دارای تصحیحی باشد که نه +1 و نه -1 است، تا نشان‌دهنده بریده شدن پرونده TZif در آغاز باشد. همچنین، اگر دو یا چند گذار ثانیه کبیسه وجود داشته باشد و مقدار تصحیح آخرین ورودی برابر با مقدار ورودی پیشین باشد، آخرین ورودی به جای یک ثانیه کبیسه نشان‌دهنده انقضای جدول ثانیه کبیسه است؛ برچسب‌های زمانی پس از این انقضا غیرقابل اعتماد هستند، زیرا نسخه‌های آینده احتمالاً ورودی‌های ثانیه کبیسه را پس از تاریخ انقضا اضافه خواهند کرد، و ثانیه‌های کبیسه افزوده‌شده نحوه رفتار با برچسب‌های زمانی پس از انقضا را تغییر خواهند داد.

تغییرات آتی در این قالب ممکن است داده‌های بیشتری را به انتهای آن بیفزاید.

پرونده‌های نسخه ۱ یک قالب موروثی و قدیمی به شمار می‌روند و نباید تولید شوند، زیرا از زمان‌های گذار پس از سال ۲۰۳۸ پشتیبانی نمی‌کنند. خوانندگانی که تنها نسخه ۱ را درک می‌کنند، باید هر داده‌ای را که فراتر از انتهای محاسبه‌شده بلوک داده نسخه ۱ قرار می‌گیرد، نادیده بگیرند.

به غیر از نسخه ۱، برنامه‌های نویسنده باید کمترین شماره نسخه مورد نیاز داده‌های پرونده را تولید نمایند. برای نمونه، یک نویسنده تنها در صورتی باید پرونده نسخه ۴ تولید کند که جدول ثانیه کبیسه آن منقضی شود یا در ابتدا بریده شده باشد. به همین ترتیب، نویسنده‌ای که پرونده نسخه ۴ تولید نمی‌کند، تنها در صورتی باید پرونده نسخه ۳ تولید کند که افزونه‌های رشته TZ برای مدل‌سازی دقیق زمان‌های گذار ضروری باشند.

دنباله تغییرات زمانی تعریف‌شده توسط سربرگ و بلوک داده نسخه ۱ باید یک زیردنباله پیوسته از تغییرات زمانی تعریف‌شده توسط سربرگ و بلوک داده نسخه ۲ به بالا و پانویس باشد. این راهنما به خوانندگان منسوخ نسخه ۱ کمک می‌کند تا در مورد برچسب‌های زمانی درون زیردنباله پیوسته با خوانندگان امروزی اتفاق نظر داشته باشند. همچنین به نویسندگانی که از خوانندگان قدیمی پشتیبانی نمی‌کنند اجازه می‌دهد برای صرفه‌جویی در فضا از tzh_timecnt برابر صفر در بلوک داده نسخه ۱ استفاده کنند.

هنگامی که یک پرونده TZif حاوی زمان انقضای جدول ثانیه کبیسه است، خوانندگان TZif باید یا از پردازش برچسب‌های زمانی پس از انقضا خودداری کنند، یا آن‌ها را به گونه‌ای پردازش نمایند که گویی زمان انقضا وجود نداشته است (احتمالاً همراه با یک نشانه خطا).

اختصارات منطقه زمانی باید دست‌کم از سه (۳) و حداکثر از شش (۶) نویسه اسکی از میان حروف و ارقام، “-” و “+” تشکیل شده باشند. این امر برای سازگاری با الزامات POSIX برای اختصارات منطقه زمانی است.

یک نام اختصاری عددی منطقه زمانی باید با اختلاف UT مطابقت داشته باشد. برای نمونه، "+0530" تنها باید در صورتی استفاده شود که اختلاف UT برابر ۵٫۵ ساعت جلوتر از UT باشد، و "-00" تنها در صورتی باید به کار رود که اختلاف UT برابر صفر باشد.

هنگام خواندن پرونده نسخه ۲ یا بالاتر، برنامه‌های خواننده باید سربرگ و بلوک داده نسخه ۱ را به جز برای رد شدن از روی آن‌ها، نادیده بگیرند.

خواننده‌ها باید به عنوان بخشی از اعتبارسنجی پرونده، طول کل سربرگ‌ها و بلوک‌های داده را محاسبه کرده و بررسی کنند که همگی در اندازه واقعی پرونده جا می‌گیرند.

هنگامی که یک ثانیه کبیسه مثبت رخ می‌دهد، خواننده‌ها باید یک ثانیه اضافی به دقیقه محلی که حاوی ثانیه درست پیش از ثانیه کبیسه است بیفزایند. اگر این رویداد هنگامی رخ دهد که اختلاف UTC مضربی از ۶۰ ثانیه نباشد، ثانیه کبیسه زودتر از آخرین ثانیه دقیقه محلی رخ می‌دهد و ثانیه‌های محلی باقی‌مانده آن دقیقه به جای ۵۹ ثانیه معمول تا ۶۰ شماره‌گذاری می‌شوند؛ اختلاف UTC دست‌نخورده باقی می‌ماند.

این بخش مشکلات متداول در خواندن یا نوشتن پرونده‌های TZif را مستند می‌کند. بیشتر این‌ها مشکلاتی در تولید پرونده‌های TZif برای استفاده توسط خوانندگان قدیمی‌تر هستند. اهداف این بخش کمک به موارد زیر است:

  • نویسندگان TZif پرونده‌هایی را خروجی دهند که از خطاهای متداول در خوانندگان قدیمی‌تر یا دارای باگ TZif دوری کنند،
  • خوانندگان TZif هنگام خواندن پرونده‌های تولیدشده توسط نویسندگان آینده TZif از خطاهای متداول اجتناب نمایند، و
  • هر نویسنده مشخصات در آینده ببیند که هنگام تغییر در قالب TZif چه نوع مشکلاتی بروز می‌کنند.

هنگامی که نسخه‌های جدیدی از قالب TZif تعریف شده‌اند، یک هدف در طراحی این بوده است که یک خواننده بتواند حتی اگر پرونده از نسخه TZif جدیدتری نسبت به آنچه خواننده برای آن طراحی شده باشد، با موفقیت از آن استفاده کند. هنگامی که سازگاری کامل حاصل نشد، تلاش شد تا اشکالات به برچسب‌های زمانی به‌ندرت استفاده‌شده محدود گردد و راهکارهای جزئی ساده در نویسندگانی که برای تولید داده‌های نسخه جدیدتر طراحی شده‌اند امکان‌پذیر شود تا حتی برای خوانندگان نسخه قدیمی‌تر نیز مفید واقع شوند. این بخش می‌کوشد این مسائل سازگاری و راهکارهای دور زدن آن‌ها و همچنین سایر باگ‌های رایج در برنامه‌های خواننده را مستند سازد.

مشکلات سازگاری متقابل با TZif شامل موارد زیر است:

  • برخی خوانندگان تنها داده‌های نسخه ۱ را بررسی می‌کنند. به عنوان یک راهکار موقت جزئی، یک نویسنده می‌تواند تا حد امکان داده‌های نسخه ۱ را خروجی دهد. با این وجود، یک خواننده باید داده‌های نسخه ۱ را نادیده بگیرد و از داده‌های نسخه ۲ به بالا استفاده کند، حتی اگر برچسب‌های زمانی بومی خواننده فقط ۳۲ بیتی باشند.
  • برخی خوانندگان طراحی‌شده برای نسخه ۲ ممکن است برچسب‌های زمانی پس از آخرین گذار پرونده نسخه ۳ یا بالاتر را به اشتباه پردازش کنند، چرا که قادر به تجزیه افزونه‌های POSIX.1-2024 نسبت به POSIX.1-2017 در رشته پیش‌بینانه TZ نیستند. به عنوان یک راهکار موقت جزئی، نویسنده می‌تواند گذارهای بیشتری نسبت به میزان لازم تولید کند، به طوری که تنها برچسب‌های زمانی در آینده بسیار دور توسط خوانندگان نسخه ۲ دچار اشکال شوند.
  • برخی خوانندگان ممکن است برچسب‌های زمانی پس از آخرین گذار پرونده را به نادرستی پردازش کنند، چرا که الزام دارند تمام اختصارات یا اختلافات UT موجود در رشته پیش‌بینانه TZ در جایی از جداول نام‌گذاری‌های منطقه زمانی و رکوردهای نوع زمان محلی پرونده نیز حضور داشته باشند. به عنوان یک راهکار، نویسنده می‌تواند گذارهای بیشتری نسبت به میزان لازم تولید کند، به طوری که جداول دیگر حاوی کپی‌هایی از اختصارات و اختلافات رشته پیش‌بینانه TZ باشند.
  • برخی خوانندگان طراحی‌شده برای نسخه ۲ از ساعت تابستانی دائمی با گذارهای پس از 24:00 پشتیبانی نمی‌کنند – برای مثال، یک رشته TZ مانند “EST5EDT,0/0,J365/25” که نشان‌دهنده ساعت تابستانی شرقی دائمی (-04) است. به عنوان یک راهکار، نویسنده می‌تواند زمان استاندارد را برای دو منطقه زمانی شرقی‌تر جایگزین کند، برای نمونه “XXX3EDT4,0/0,J365/23” برای یک منطقه زمانی با یک زمان استاندارد هرگز استفاده‌نشده (XXX, -03) و ساعت تابستانی منفی (EDT, -04) در سراسر سال. به عنوان راهکار دیگر، نویسنده می‌تواند زمان استاندارد را برای منطقه زمانی بعدی در شرق جایگزین نماید – برای مثال “AST4” برای زمان استاندارد دائمی اطلس (-04).
  • برخی خوانندگان طراحی‌شده برای نسخه ۲ یا ۳ که نیازمند انطباق دقیق با RFC 9636 هستند، پرونده‌های نسخه ۴ را که جداول ثانیه کبیسه آن‌ها در ابتدا بریده شده یا به زمان‌های انقضا ختم می‌شوند رد می‌کنند.
  • برخی خوانندگان پانویس را نادیده می‌گیرند و در عوض، برچسب‌های زمانی آینده را بر اساس نوع زمان آخرین گذار پیش‌بینی می‌کنند. به عنوان یک راهکار موقت جزئی، نویسنده می‌تواند گذارهای بیشتری نسبت به میزان لازم تولید کند.
  • برخی خوانندگان ساده‌سازی‌شده همه‌چیز به جز پانویس را نادیده می‌گیرند و از رشته پیش‌بینانه TZ آن برای محاسبه تمام برچسب‌های زمانی استفاده می‌کنند. اگرچه این روش اغلب برای برچسب‌های زمانی کنونی و آینده به درستی کار می‌کند، اما مشخصاً با برچسب‌های زمانی گذشته دچار مشکل است، و حتی برای برچسب‌های زمانی کنونی نیز ممکن است برای تنظیماتی مانند TZ="Africa/Casablanca" با شکست مواجه شود. این حالت متناظر با یک پرونده TZif است که شامل گذارهای صریح تا سال ۲۰۸۷ بوده و پس از آن پانویسی حاوی رشته TZ “<+01>-1” قرار دارد که فقط باید برای برچسب‌های زمانی پس از آخرین گذار صریح استفاده شود.
  • برخی خوانندگان برای برچسب‌های زمانی قبل از نخستین گذار از نوع زمان ۰ استفاده نمی‌کنند، به این ترتیب که یک نوع زمان را با استفاده از یک روش اکتشافی (heuristic) استنباط می‌کنند که همیشه نوع زمان ۰ را انتخاب نمی‌کند. به عنوان یک راهکار موقت جزئی، نویسنده می‌تواند یک گذار صوری (بی‌اثر) اولیه را در زمانی در گذشته دور خروجی دهد.
  • برخی خوانندگان برچسب‌های زمانی پیش از نخستین گذاری را که برچسب زمانی آن کمتر از -2**31 نیست، به نادرستی پردازش می‌کنند. خوانندگانی که تنها از برچسب‌های زمانی ۳۲ بیتی پشتیبانی می‌کنند بیشتر مستعد این مشکل هستند؛ مثلاً هنگامی که گذارهای ۶۴ بیتی را پردازش می‌کنند که تنها برخی از آن‌ها در ۳۲ بیت قابل نمایش هستند. به عنوان یک راهکار جزئی، نویسنده می‌تواند یک گذار ساختگی در برچسب زمانی -2**31 ایجاد کند.
  • برخی خوانندگان اگر برچسب زمانی یک گذار دارای کمترین مقدار ممکن علامت‌دار ۶۴ بیتی باشد، آن را به اشتباه پردازش می‌کنند. برچسب‌های زمانی کمتر از -2**59 توصیه نمی‌شوند.
  • برخی خوانندگان رشته‌های پیش‌بینانه TZ حاوی “<” یا “>” را به اشتباه پردازش می‌کنند. به عنوان یک راهکار موقت جزئی، نویسنده می‌تواند از به کار بردن “<” یا “>” برای اختصارات منطقه زمانی که فقط حاوی نویسه‌های الفبایی هستند خودداری کند.
  • بسیاری از خوانندگان اختصارات منطقه زمانی حاوی نویسه‌های غیر اسکی را به اشتباه پردازش می‌کنند. این نویسه‌ها توصیه نمی‌شوند.
  • برخی خوانندگان ممکن است اختصارات منطقه زمانی را که شامل کمتر از ۳ یا بیشتر از ۶ نویسه هستند، یا حاوی نویسه‌های اسکی غیر از حروف و ارقام، “-” و “+” باشند، به نادرستی پردازش کنند. این اختصارات توصیه نمی‌شوند.
  • برخی خوانندگان پرونده‌های 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 از ۶۰ ثانیه رخ می‌دهند، برچسب‌های زمانی مبهم تولید می‌کنند. برای مثال، با اختلاف UTC برابر +01:23:45 و یک ثانیه کبیسه مثبت 78796801 (1972-06-30 23:59:60 UTC)، برخی خوانندگان هر دو برچسب زمانی 78796800 و 78796801 را به جای نگاشت دومی به 01:23:46، به زمان محلی 01:23:45 روز بعد نگاشت می‌کنند و برچسب زمانی 78796815 را به جای 01:23:60 به 01:23:59 می‌نگارند. این مورد هنوز در عمل یک مشکل نبوده است، چرا که هیچ مرجع رسمی از زمان معرفی ثانیه‌های کبیسه در سال ۱۹۷۲ چنین اختلاف‌های UTC را وضع نکرده است.

برخی از مشکلات سازگاری متقابل، باگ‌های موجود در خواننده‌ها هستند که در اینجا عمدتاً به عنوان هشدارهایی برای توسعه‌دهندگان برنامه‌های خواننده ذکر شده‌اند.

  • برخی خوانندگان از برچسب‌های زمانی منفی پشتیبانی نمی‌کنند. توسعه‌دهندگان برنامه‌های توزیع‌شده در صورت نیاز به کار با داده‌های پیش از ۱۹۷۰ باید این نکته را مد نظر قرار دهند.
  • برخی خوانندگان برچسب‌های زمانی پیش از نخستین گذاری را که دارای برچسب زمانی غیرمنفی است، به اشتباه پردازش می‌کنند. خوانندگانی که از برچسب‌های زمانی منفی پشتیبانی نمی‌کنند، احتمالاً بیشتر مستعد این مشکل هستند.
  • برخی خوانندگان اختصارات منطقه زمانی مانند “-08” را که شامل “+”، “-” یا ارقام هستند، به اشتباه پردازش می‌کنند.
  • برخی خوانندگان اختلافات UT خارج از محدوده سنتی -12 تا +12 ساعت را به اشتباه پردازش می‌کنند و بنابراین از مکان‌هایی نظیر کیریتیماتی (Kiritimati) که خارج از این محدوده هستند پشتیبانی نمی‌کنند.
  • برخی خوانندگان اختلافات UT در محدوده [-3599, -1] ثانیه نسبت به UT را به نادرستی پردازش می‌کنند زیرا اختلاف را با تقسیم صحیح بر ۳۶۰۰ برابر با ۰ قرار می‌دهند و سپس بخش ساعت را به صورت “+00” نمایش می‌دهند.
  • برخی خوانندگان اختلافات UT را که مضربی از یک ساعت، یا ۱۵ دقیقه، یا ۱ دقیقه نیستند، به اشتباه پردازش می‌کنند.

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

Olson A, Eggert P, Murchison K. The Time Zone Information Format (TZif). October 2024. Internet RFC 9636 doi:10.17487/RFC9636.

Time Zone Database