مناطق زمانی و حساسیت

1) اصول اساسی

UTC به عنوان حمل و نقل و ذخیره سازی. تمام زمان های سرور و کلید های مرتب سازی در UTC هستند. تبدیل به زمان محلی «دیوار» - در لبه (لبه/UI) و یا در یک سرویس قالب بندی خاص اختصاص داده شده است.
منطقه ≠ افست «اروپا/کیف» فقط «UTC + 02:00» نیست: قوانین در طول زمان تغییر می کنند. شناسه های IANA (tzdb) را در نمایه کاربر/شیء ذخیره کنید، نه «+ 03:00».

تمایز ساعت روشن

ساعت دیواری (زمان انسان، با توجه به DST).
ساعت UTC (مقیاس جهانی).
ساعت مونوتونیک (برای اندازه گیری مدت زمان و مدت زمان). هرگز ساعت دیواری را محاسبه نکنید.
Idempotency و تحمل به لرزش زمان. سیستم ها باید به درستی از جهش های کوچک NTP/offset جان سالم به در ببرند.

2) مدل داده ها و قراردادهای API

رویدادها: «رخ داد در» (UTC، RFC 3339)، «منطقه زمانی» (IANA)، به صورت اختیاری «wall _ time» (محلی با افست در هنگام ایجاد).
دوره ها: استفاده از فواصل نیمه بسته '[شروع، پایان)' در UTC ؛ برای برنامه های قابل خواندن انسان، عبارت اصلی + منطقه را حفظ کنید.
قوانین تکراری: سریال به عنوان RRULE/cron معادل + منطقه IANA. برنامهریزی را به موتوری محول کنید که DST را درک میکند.
فرمت زمانی در API: ISO 8601/RFC 3339 با «Z» صریح یا افست، به عنوان مثال «2025-10-31T17: 00: 00Z». خطوط شناور را بدون افست عبور ندهید.
Versioning: تغییر قوانین کسب و کار زمان (به عنوان مثال، تغییر یک کشور به ثابت UTC + 1) مهاجرت تنظیمات و محاسبه مجدد برنامه است ؛ در طرح های انتشار در نظر بگیرید.

3) Daylight Saving Time (DST): ابهامات و حذفیات

زمان های محلی را کپی کنید. در پاییز، محلی «02:30» می تواند دو بار اتفاق بیفتد. برنامه ریزان در منطقه باید بین 2025-10-26T02: 30 + 03 و 2025-10-26T02: 30 + 02 تمایز قائل شوند.
زمان های محلی از دست رفته در بهار، فواصل دقیقه «پرش» (به عنوان مثال، '02: 00-03: 00' وجود ندارد). برنامه ریز باید استراتژی را تعیین کند: حرکت به «03:00»، پرش یا اجرای «در اسرع وقت».
توصیه: کار را به عنوان یک «قانون محلی + منطقه» ذخیره کنید و موارد واقعی را در UTC پیش بینی کنید (پنجره نورد)، سیاست انتخاب شده در DST را ثابت کنید.

4) پرش ثانیه и زمان لکه

ثانیه پرش کن گاهی اوقات یک ثانیه اضافی در UTC وارد می شود. اکثر فرآیندهای کسب و کار نباید «ببینید» 23:59:60.
لکه دار کردن برخی از محیط ها به آرامی تنظیم در هر پنجره (به عنوان مثال، ± 12 ساعت) را برای جلوگیری از پرش توزیع می کنند.
تمرین: در مورد یک سیاست زمانی واحد برای کل خوشه (NTP/smir) موافقت کنید، آن را در ابرداده وارد کنید و آن را در runbook نگه دارید.

5) برنامه ریزان و الگوهای cron

خطر «cron ساده» cron کلاسیک مناطق DST و IANA را نمی شناسد. استفاده از موتورهای که در آن برنامه منطقه محدود است (کلاس کوارتز, خدمات ابر برنامه ریز, Kubernetes CronJob با منطقه از طریق کنترل/مدیریت).
تحقق برنامه ها برای قابلیت اطمینان، N بعدی را در UTC اجرا کنید (به عنوان مثال، برای 7-30 روز)، مکان نما را ذخیره کنید و سیاست را در DST تعیین کنید.
بی تفاوتی از وظایف. تقسیم بندی Ключ: '(job_id، scheduled_at_utc) ؛ شروع مجدد نباید عوارض جانبی تکراری داشته باشد.
لغزش ساعت برای مکث های طولانی/حوادث، تصمیم بگیرید که آیا برای گرفتن یا جست و خیز. پیکربندی در هر کار.

6) زمان در پروتکل ها و صف ها

اتوبوس های رویداد (کافکا/پولسار). «event _ time» و «ingest _ time» را جداگانه ذخیره کنید. از event _ time برای تخصیص های گذشته نگر استفاده کنید.
مصرف کنندگان بی نظیر هنگام تحویل مجدد، به جای افست در دسته، روی کلید رویداد و «event _ time» تمرکز کنید.
مرتب سازی و پنجره ها پنجره های «زمان فروشگاه محلی 24 ساعته» را به عنوان فواصل UTC به دست آمده از قوانین محلی یک منطقه خاص برای یک تاریخ خاص محاسبه کنید.

7) سیاهههای مربوط، آثار، معیارها

استاندارد منطقه زمانی یکپارچه: تمام سیاهههای فنی و معیارها در UTC (نشان دهنده «Z»). نمایش در داشبورد - محلی برای کاربر.
Trace - Pass 'trace _ start _ utc', 'duration _ ms' on a monotonic clock. هرگز برچسب زمانی «دیوار» را کم نکنید.

گزارش کسب و کار: فرم «روز» در منطقه دامنه (به عنوان مثال «اروپا/پاریس» برای مالیات فرانسه) به جای UTC. مستند سازی به وضوح

8) پروفایل های کاربر و محتوا

Профиль: 'preferred _ timezone' (IANA), 'preferred _ locale', 'currency', 'week _ start' (دوشنبه/یکشنبه).
نهادهای چند منطقه ای: برای تیم ها/سازمان ها، «منطقه دامنه» (به عنوان مثال، یک فروشگاه/نهاد قانونی) بدون در نظر گرفتن منطقه شخصی شرکت کننده.
اطلاعیه ها: محاسبه «ساعت آرام» در منطقه کاربر ؛ ارسال از پنجره UTC، با امنیت DST.

9) ضد الگوهای

فقط به وقت محلی بدون افست/منطقه ذخیره کنید.
افست هارد فلش «+ hh: mm» به جای شناسه IANA.
محاسبه مدت زمان از طریق تفاوت دو «دیوار» timestamps.
طرح توسط cron بدون منطقه/پشتیبانی DST.
تجزیه و تحلیل «روز به روز» را در UTC انجام دهید، زمانی که استاندارد نیاز به یک منطقه محلی دارد.
تغییر ناپذیری قوانین منطقه را فرض کنید (کشورها سیاست زمان را تغییر می دهند).

10) تست زمان

ساعت های کنترل شده «ساعت» را به کد (Clock/TimeProvider) برای تست های قطعی تزریق کنید.

• زمان صرفه جویی در نور روز (dubs/skips) تغییر می کند.
• حرکت کاربر بین مناطق (تغییر 'preferred _ timezone').
• تغییر قانون در tzdb (به روز رسانی پایه - آزمون رگرسیون).
• NTP آفست، تحویل تاخیر از حوادث.
• تست های فازی مناطق تصادفی، تاریخ، فرمت ؛ مقایسه با یک کتابخانه مرجع

11) قابلیت مشاهده و عملکرد

هشدارها: ناهماهنگی NTP، تاخیر به روز رسانی tzdb، انفجار وظایف cron «unfulfilled» با DST.
داشبورد: توزیع رویدادها توسط مناطق/روزهای محلی ؛ گرفتن/پرش شمارنده.
Runbook: روش هایی برای تغییر قوانین زمان در حوزه قضایی ؛ tzdb سفارش به روز رسانی ارتباط با صاحبان برنامه.

12) الگوهای پیاده سازی

دروازه عادی سازی زمان. یک سرویس ظریف که زمانهای ورودی به RFC 3339 UTC را عادی می کند، مناطق (IANA) را تأیید می کند و زمینه را تکمیل می کند.
سازنده روز محلی یک کتابخانه/سرویس که مرزهای دقیق UTC را از «روز محلی» و منطقه، با در نظر گرفتن DST ایجاد می کند.
برنامه ریزی مواد یک برنامه ریز که قوانین را به عنوان «عبارت محلی + منطقه» ذخیره می کند، موارد آینده را در UTC تحقق می بخشد و تصادفات/حذفیات را مدیریت می کند.
رویدادهای زمانبندی دوگانه. رویدادها با فیلدهای «رخ داد در _ utc»، «wall _ time _ local»، «منطقه زمانی». محلی برای UI، UTC برای سیستم ها جایگزین شده است.

13) چک لیست معمار

1. آیا UTC در همه جا ذخیره می شود ؟

2. آیا سازمان دارای یک منطقه IANA و یک سیاست داده دامنه است ؟

3. آیا زمانبندی DST را درک می کند و موارد را در UTC تحقق می بخشد ؟

4. سیاههها/معیارها - در UTC ؛ گزارش ها - در منطقه دامنه ؟

5. وقفه/عقب نشینی - در یک ساعت یکنواخت ؟

6. آیا به روز رسانی tzdb به صورت خودکار و تحت نظارت است ؟

7. تست پوشش تغییرات قانون، دو برابر/دقیقه از دست رفته ؟

14) دستور العمل های کوچک (شبه کد)

تبدیل محلی «روز کاری» به فاصله UTC

function localDayToUtcInterval(dateLocal, tz):
startLocal = combine(dateLocal, 00:00) in tz endLocal  = startLocal + 1 day startUtc  = toUTC(startLocal) // учитывает DST endUtc   = toUTC(endLocal)
return [startUtc, endUtc)

تحقق یک برنامه تکراری

inputs: rrule, tz, windowStartUtc, windowEndUtc for each localOccurrence in expand(rrule, tz, [windowStartUtc, windowEndUtc] projected to tz):
emit occurrence { scheduled_at_utc = toUTC(localOccurrence), tz }

کلید شروع کار idempotent

dedupe_key = hash(job_id + scheduled_at_utc.toString())

15) ایمنی و انطباق

حسابرسی: نگه داشتن هر دو پیش بینی زمان (UTC و محلی) برای آشتی دادن ادعاهای کاربر («من قبل از ساعت 11 وعده داده شد لیما») با گاهشناسی سرور.
مقررات: دوره های گزارش دهی در مناطق مورد نیاز (مالیات، محدودیت های بازی مسئول، محدودیت های بازاریابی «ساعت») تشکیل می شود.
حریم خصوصی: منطقه زمانی - تنظیمات شخصی، اما اطلاعات دقیق شناسایی نیست ؛ فرآیند در سیاست های حفظ حریم خصوصی مشترک.

نتیجه گیری

«حساسیت به زمان» در مورد فرمت تاریخ نیست، بلکه در مورد مرزهای معماری مسئولیت است: جایی که برای ذخیره، جایی که برای تبدیل، چگونگی برنامه ریزی و چگونگی اثبات صحت. وحدت UTC، مناطق صریح IANA، برنامه ریزان صالح، زمان بندی دوگانه و ساعتهای یکنواخت، زمان را از یک منبع حوادث به یک سرویس زیربنایی قابل پیش بینی تبدیل می کند.

• GeoDNS و مسیریابی جغرافیایی ؛ تعادل بار ؛ قابلیت مشاهده وقایع در طول زمان ؛ الگوهای Cron و برنامه ریزی مواد ؛ محدودیت های منطقه ای و روزهای گزارش دهی محلی