დროის ზონები და მგრძნობელობა

1) ძირითადი პრინციპები

UTC, როგორც ტრანსპორტი და შენახვა. ყველა სერვერის დრო და დახარისხების გასაღებები UTC- ში არის. ტრანსფორმაცია ადგილობრივ „კედელზე“ - ზღვარზე (edge/UI) ან სპეციალურად გამოყოფილი ფორმატის სერვისში.
ზონა. 'Europe/Kyiv' არ არის მხოლოდ 'UTC + 02:00': წესები იცვლება დროთა განმავლობაში. შეინახეთ იდენტიფიკატორები IANA (tzdb) მომხმარებლის/ობიექტის პროფილში და არა „+ 03:00“.
საათის მკაფიო განსხვავება.

Wall clock (ადამიანის დრო ექვემდებარება DST).
UTC clock (უნივერსალური მასშტაბი).
Monotonic clock (ხანგრძლივობისა და ტაიმაუტის გასაზომად). არასოდეს გამოთვალოთ ტაიმაუტები „კედლის“ საათებში.
Idempotence და ტოლერანტობა დროის ტრიალისკენ. სისტემებმა სწორად უნდა განიცდიან მცირე NTP/გადაადგილების რბოლებს.

2) მონაცემთა მოდელი და API კონტრაქტები

მოვლენები: 'occurred _ at' (UTC, RFC 3339), 'timezone' (IANA), სურვილისამებრ 'wall _ time' (ადგილობრივი გადაადგილების შენარჩუნება შექმნის დროს).
პერიოდები: გამოიყენეთ ნახევრად დახურული ინტერვალები '[start, end)' UTC- ში; ადამიანური განრიგისთვის შეინახეთ საწყისი გამოთქმა + ზონა.
განმეორებითი წესები: სერია, როგორც RRULE/cron ეკვივალენტი + IANA ზონა. დაგეგმვა დელეგირებულია ძრავაზე, რომელსაც ესმის DST.
დროის ფორმატი API- ში: ISO 8601/RFC 3339 აშკარა 'Z' ან გადაადგილებით, მაგალითად, '2025-10-31T17: 00: 00Z'. გადაიტანეთ „მცურავი“ ხაზები გადაადგილების გარეშე.
ვერსია: ბიზნეს დროის წესების ცვლილება (მაგალითად, ქვეყნის გადასვლა მუდმივ UTC + 1) არის კონფიგურაციის მიგრაცია და გრაფიკების გადაანგარიშება; გაითვალისწინეთ ვერსიის სქემები.

3) ზაფხულის დრო (DST): ამბიგუეტები და გამოტოვება

დუბლირებული ადგილობრივი დრო. შემოდგომაზე, ადგილობრივი „02:30“ შეიძლება ორჯერ მოხდეს. ზონაში შემგროვებელმა უნდა განასხვავოს '2025-10-26T02: 30 + 03' და '2025-10-26T02: 30 + 02'.
გამოტოვებული ადგილობრივი დრო. გაზაფხულზე, წუთიერი ინტერვალები „გადახტა“ (მაგალითად, '02: 00-03: 00' არ არსებობს). დამგეგმავი ვალდებულია განსაზღვროს სტრატეგია: გადაიდო „03:00 საათზე“, გამოტოვოს ან შეასრულოს „რაც შეიძლება მალე“.
რეკომენდაცია: შეინახეთ დავალება, როგორც „ადგილობრივი წესი + ზონა“, ხოლო ფაქტობრივი ინსტანციები წინასწარ უნდა მოხდეს UTC- ში (rolling window), DST- ზე არჩეული პოლიტიკის დაფიქსირებით.

4) Leap seconds и time smear

Leap second. დამატებითი წამი ზოგჯერ ჩასმულია UTC- ში. ბიზნეს პროცესების უმეტესობა არ უნდა „ნახოს“ 23:59:60.
Smear (გაჟონვა). ზოგი გარემო რბილად ანაწილებს კორექტირებას ფანჯარასთან (მაგალითად, ± 12 საათი), რათა თავიდან აიცილოს ნახტომი.
პრაქტიკა: შეთანხმდით დროის ერთიან პოლიტიკას მთელი კლასტერისთვის (NTP/სმირი), მოაწყეთ იგი მეტამონაცემებში და შეინახეთ იგი runbook- ში.

5) დაგეგმვა და cron ნიმუშები

„მარტივი cron“ - ის საშიშროება. კლასიკურმა cron- მა არ იცის DST და IANA ზონები. გამოიყენეთ ძრავები, სადაც გრაფიკი უკავშირდება ზონას (Quartz კლასი, ღრუბლოვანი Scheduler სერვისები, Kubernetes CronJob ზონასთან ერთად კონტროლერის/ადმისიის საშუალებით).
გრაფიკის მატერიალიზაცია. საიმედოობის უზრუნველსაყოფად, შემდეგი N გაშვება UTC- ში (მაგალითად, 7-30 დღის განმავლობაში), შეინახეთ cursor და შეინახეთ პოლიტიკა DST- ში.
დავალებების idempotence. Ключ deduplication: `(job_id, scheduled_at_utc)`; ხელახალი გაშვება არ უნდა იყოს დუბლირებული გვერდითი მოვლენებისთვის.
საათის სრიალი. გრძელი პაუზებით/ინციდენტებით, გადაწყვიტეთ გააკეთოთ თუ არა catch-up (შეასრულეთ გამოტოვებული) ან skip. კონფიგურაცია per-job.

6) დრო ოქმებსა და რიგებში

ღონისძიების საბურავები (კაფკა/პულსარი). შეინახეთ 'event _ time' და 'ingest _ time' ცალკე. რეტროსპექტული გადაანგარიშებისთვის გამოიყენეთ 'ღონისძიება _ დრო ".
Idempotent მომხმარებლები. ხელახლა მიწოდებისას, ყურადღება გაამახვილეთ ღონისძიების გასაღებზე და 'ღონისძიებაზე _ დროში "და არა პარტიაში გადასვლაზე.
დახარისხება და ფანჯრები. ფანჯრები „მაღაზიის ადგილობრივი დროით 24 საათში“ გამოთვალეთ, როგორც UTC ინტერვალები, რომლებიც მიიღება კონკრეტული ზონის ადგილობრივი წესებიდან კონკრეტული თარიღისთვის.

7) ლოგები, კვალი, მეტრიკა

ერთი ტაიმზონის სტანდარტი: UTC- ში არსებული ყველა ტექნიკური ლოგო და მეტრი (მითითებულია 'Z'). დაშბორდში რუქა მომხმარებლისთვის ლოკალიზებულია.
ტრეკები: გადასცეს 'trace _ start _ utc', 'duration _ ms' მონოტონურ საათებში. არასოდეს გამოთვალოთ „კედლის“ დრო.
ბიზნეს მოხსენებები: შექმნათ „დღე“ დომენის ზონაში (მაგალითად, „ევროპა/პარიზი“ საფრანგეთის გადასახადისთვის) და არა UTC- სთვის. მკაფიოდ განსაზღვრეთ.

8) მომხმარებლის პროფილები და შინაარსი

Профиль: `preferred_timezone` (IANA), `preferred_locale`, `currency`, `week_start` (Mon/Sun).
მულტიზონური არსებები: გუნდებისთვის/ორგანიზაციებისთვის შეინახეთ „დომენის ზონა“ (მაგალითად, მაღაზია/იურიდიული პირი), მიუხედავად მონაწილის პირადი ზონისა.
ნოტიფიკაცია: გამოთვალეთ „მშვიდი საათი“ მომხმარებლის ზონაში; ქურთუკის გაგზავნა UTC- ფანჯრებიდან, უსაფრთხოებით DST- ზე.

9) ანტი შაბლონები

შეინახეთ მხოლოდ ადგილობრივი დრო გადაადგილების/ზონის გარეშე.
IANA- ს იდენტიფიკატორის ნაცვლად მკაცრად გადაადგილება „+ hh: mm“.
ხანგრძლივობის დათვლა ორი „კედლის“ დროის სხვაობით.
დაგეგმეთ cron ზონების მხარდაჭერის გარეშე/DST.
გააკეთეთ ანალიტიკა „დღის განმავლობაში“ UTC- ში, როდესაც სტანდარტი მოითხოვს ადგილობრივ ზონას.
ზონის წესების უცვლელობა (ქვეყნები ცვლის დროის პოლიტიკას).

10) დროის ტესტირება

კონტროლირებადი საათი. ინექცია „საათი“ კოდში (კლოკი/TimeProvider) დეტერმინის ტესტებისთვის.

• გადასვლა ზაფხულში/ზამთარში (დუბლირება/გამოტოვება).
• მომხმარებლის გადაადგილება ზონებს შორის (შეცვლა 'preferred _ timezone').
• Tzdb წესების ცვლილება (ბაზის განახლება - რეგრესიული ტესტები).
• NTP- ის გადაადგილება, დაკავებულია მოვლენების მიტანა.
• ფაზის ტესტები. შემთხვევითი ზონები, თარიღები, ფორმატები; საცნობარო ბიბლიოთეკის შედარება.

11) დაკვირვება და ექსპლუატაცია

ალერტები: NTP- ის რასინქრონიზაცია, tzdb- ის განახლების ჩამორჩენა, DST- ში „შეუსრულებელი“ cron დავალებების ზრდა.
დაშბორდები: მოვლენების განაწილება ზონების/ადგილობრივი დღის მიხედვით; catch-up/skip მრიცხველები.
Runbook: პროცედურები იურისდიქციაში დროის წესების შეცვლისას; tzdb განახლების წესი; კომუნიკაცია გრაფიკის მფლობელებთან.

12) განხორციელების ნიმუშები

Time Normalization Gateway. თხელი სერვისი, რომელიც ნორმალიზებს შემომავალი დროების RFC 3339 UTC- ს, წამყვან ზონებს (IANA) და ავსებს კონტექსტს.
Local-Day Builder. ბიბლიოთეკა/სერვისი, რომელიც „ადგილობრივი დღიდან“ და ზონიდან აშენებს ზუსტი UTC საზღვრებს „[start _ utc, end _ utc)“, DST- ის გათვალისწინებით.
Schedule Materializer. დამგეგმავი, რომელიც ინახავს წესებს „ადგილობრივი გამოხატვის + ზონის“ სახით, მატერიალიზაციას უწევს მომავალ ინსტანციებს UTC- ში და აკონტროლებს კოლიზიებს/უღელტეხილებს.
Dual-Timestamp Events. მოვლენები „occurred _ at _ utc“, „wall _ time _ ადგილობრივი“, „timezone“. UI- სთვის ადგილობრივი ჩანაცვლება ხდება, სისტემებისთვის - UTC.

13) არქიტექტორის ჩეკის სია

1. ყველგან არის UTC?
2. აქვს IANA ზონა და დომენის მონაცემთა პოლიტიკა?
3. დამგეგმავი ესმის DST და მატერიალიზაციას უწევს ინსტანციებს UTC- ში?
4. Logs/მეტრიკა - UTC- ში; ცნობები დომენის ზონაში?
5. Taimauts/retrais - მონოტონური საათები?
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 }

დავალების დაწყების იდემპოტენტური გასაღები

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

15) უსაფრთხოება და შესაბამისობა

აუდიტი: შეინახეთ დროის ორივე პროექცია (UTC და ადგილობრივი) მომხმარებლის პრეტენზიების კოორდინაციისთვის („მათ პირობა დადეს ლიმას 23:00 საათამდე“) სერვერის ქრონოლოგიასთან.
მარეგულირებელი: საანგარიშო პერიოდები იქმნება საჭირო ადგილებში (გადასახადები, პასუხისმგებელი თამაშის შეზღუდვები, მარკეტინგული შეზღუდვები „საათის განმავლობაში“).
კონფიდენციალურობა: დროის ზონა - პერსონალური პარამეტრები, მაგრამ არა ზუსტად იდენტიფიცირებული მონაცემები; დამუშავება საერთო კონფიდენციალურობის პოლიტიკის ფარგლებში.

დასკვნა

„დრო მგრძნობელობა“ არ ეხება თარიღის ფორმატს, არამედ პასუხისმგებლობის არქიტექტურულ საზღვრებს: სად უნდა შეინახოთ, სად გადაკეთდეთ, როგორ დაგეგმოთ და როგორ დაამტკიცოთ სისწორე. UTC- ს დონეზე გაერთიანება, IANA- ს აშკარა ზონები, კომპეტენტური დამგეგმავები, ორმაგი დრო და მონოტონური საათი ინციდენტების წყაროდან გადაქცევას პროგნოზირებულ ინფრასტრუქტურულ მომსახურებად აქცევს.

• GeoDNS და გეო მარშრუტიზაცია; დატვირთვის დაბალანსება; დროის მოვლენების დაკვირვება; Cron ნიმუშები და გრაფიკების მატერიალიზაცია; რეგიონალური შეზღუდვები და ადგილობრივი საანგარიშო დღე.