Уақыт белдеулері және сезімталдық

1) Базалық қағидаттар

UTC көлік және сақтау ретінде. Барлық сервер таймстемптері мен сұрыптау кілттері - UTC. Жергілікті «қабырға» уақытына түрлендіру - шетінде (edge/UI) немесе арнайы бөлінген пішімдеу сервисінде.
≠ ығысу аймағы. 'Europe/Kyiv' - бұл жай ғана 'UTC + 02:00' емес: ережелер уақыт өте келе өзгереді. IANA (tzdb) идентификаторларын «+ 03:00» емес, пайдаланушы/нысан профилінде сақтаңыз.
Сағаттарды нақты ажырату.

Wall clock (адам уақыты, DST ұшыраған).
UTC clock (әмбебап шкала).
Monotonic clock (ұзақтықтар мен таймауттарды өлшеу үшін). «Қабырға» сағаттарындағы таймауттарды ешқашан есептемеңіз.
Уақыттың діріліне төзімділік пен төзімділік. Жүйелер NTP/ығысудың аздаған секірістерін дұрыс бастан кешіруі тиіс.

2) Деректер моделі және API-келісімшарттар

Оқиғалар: 'occurred _ at' (UTC, RFC 3339), 'timezone' (IANA), қосымша 'wall _ time' (жасау кезінде ығысуды сақтай отырып жергілікті).
Кезеңдер: UTC ішіндегі жартылай жабық '[start, end)' аралықтарын пайдаланыңыз; адам оқитын кестелер үшін бастапқы өрнекті + аймақты сақтаңыз.
Қайталанатын ережелер: RRULE/cron баламасы + IANA аймағы ретінде сериалдаңыз. Жоспарлауды DST түсінетін қозғалтқышты жіберіңіз.
API-дегі уақыт форматы: айқын 'Z' немесе ығысуы бар ISO 8601/RFC 3339, мысалы '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' -ге көшіру, өткізіп жіберу немесе «мүмкіндігінше тезірек» орындау.
Ұсыным: тапсырманы «жергілікті ереже + аймақ» ретінде сақтаңыз, ал нақты инстанцияларды DST-де таңдалған саясатты белгілеп, алдын ала UTC-де (rolling window) материализациялаңыз.

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 бақылаушы/әкімші арқылы аймағы бар).
Кестелерді материалдандыру. Сенімділік үшін UTC-дегі жақын арадағы N-ді материалдандырыңыз (мысалы, 7-30 күнге), cursor сақтаңыз және DST-дегі саясатты анықтаңыз.
Тапсырмалар сәйкестігі. Ключ deduplication: `(job_id, scheduled_at_utc)`; қайта іске қосу жанама әсерлерді қайталамауы керек.
Сағат жылжуы. Ұзақ үзілістерде/оқыс оқиғаларда catch-up немесе skip жасауыңызды шешіңіз. per-job бағдарламасын теңшеңіз.

6) Хаттамалар мен кезектердегі уақыт

Оқиға шиналары (Kafka/Pulsar). 'event _ time' және 'ingest _ time' файлдарын бөлек сақтаңыз. Ретроспективті қайта есептеулер үшін 'event _ time' пайдаланыңыз.
Іспеттес тұтынушылар. Қайта жеткізу кезінде партияға ауысу емес, оқиға кілтіне және 'event _ time' бағдарланыңыз.
Сұрыптау және терезелер. «Дүкеннің жергілікті уақыты бойынша 24 сағат ішінде» терезелерін нақты күнгі нақты аймақтың жергілікті ережелерінен алынған UTC-аралықтар ретінде есептеңіз.

7) Трасса, метрика логтары

Бірыңғай таймзон стандарты: UTC-дегі барлық техникалық логтар мен өлшемдер ('Z' көрсетумен). Дашбордтарда көрсету - пайдаланушы үшін оқшауланған.
Трассировкалар: 'trace _ start _ utc', 'duration _ ms' дегенді монотонды сағаттарда беріңіз. «Қабырға» таймстемпін ешқашан есептен шығармаңыз.
Бизнес-есептер: UTC бойынша емес, домен аймағында «тәулік» жасаңыз (мысалы, француз салығы үшін «Europe/Paris»). Нақты құжаттаңыз.

8) Пайдаланушы профильдері мен мазмұны

Профиль: `preferred_timezone` (IANA), `preferred_locale`, `currency`, `week_start` (Mon/Sun).
Мультизондық мәні: командалар/ұйымдар үшін қатысушының дербес аймағына қарамастан «домен аймағын» (мысалы, дүкен/заңды тұлға) сақтаңыз.
Нотификациялар: пайдаланушы аймағындағы «тыныш сағаттарды» есептеңіз; DST кезінде қауіпсіздікпен UTC терезесінен жіберіңіз.

9) Қарсы үлгілер

Тек жергілікті уақытты ығыстырмай сақтау.
IANA идентификаторының орнына '+ hh: mm' ығысуын қатты тігу.
Ұзақтықты екі «қабырға» таймстемпінің айырмашылығы арқылы есептеу.
Аймақтарды/DST қолдауынсыз cron бойынша жоспарлау.
Нормативтік жергілікті аймақты талап еткен кезде UTC-де «тәулік бойынша» талдау жасау.
Аймақ ережелерінің өзгермейтіндігін болжау (елдер уақыт саясатын өзгертеді).

10) Уақытты тестілеу

Бақыланатын сағат. Детерминирленген тесттер үшін «сағаттарды» кодқа (Clock/TimeProvider) енгізіңіз.

• Жазғы/қысқы уақытқа ауысу (дубль/рұқсатнама).
• Пайдаланушыны аймақтар арасында жылжыту ('preferred _ timezone' алмастыру).
• tzdb ережелерін өзгерту (дерекқорды жаңарту - регрессиялық тесттер).
• NTP ығысуы, оқиғаларды кешіктіру.
• Фаззи-тестілер. Кездейсоқ аймақтар, күндер, пішімдер; эталондық кітапханамен салыстыру.

11) Бақылау және пайдалану

Alerts: NTP-ны синхрондамау, tzdb жаңартуының артта қалуы, DST кезінде «орындалмаған» cron тапсырмаларының жарылысы.
Дашбордтар: оқиғаларды аймақтар/жергілікті тәуліктер бойынша бөлу; catch-up/skip есептеуіштері.
Runbook: юрисдикциядағы уақыт ережелерін ауыстыру процедуралары; tzdb жаңарту тәртібі; кесте иелерімен байланыс.

12) Сату паттерндері

Time Normalization Gateway. RFC 3339 UTC кіріс уақытын қалыпқа келтіретін, аймақтарды валидациялайтын (IANA) және контексті толықтыратын жұқа сервис.
Local-Day Builder. DST-ді ескере отырып, «жергілікті күн» мен аймақтан нақты UTC шекараларын «[start _ utc, end_utc)» құратын кітапхана/қызмет.
Schedule Materializer. Ережелерді «жергілікті өрнек + аймақ» түрінде сақтайтын жоспарлаушы UTC-дегі болашақ әрекеттерді материалдандырады және коллизияларды/рұқсатнамаларды басқарады.
Dual-Timestamp Events. 'occurred _ at _ utc', 'wall _ time _ local', 'timezone' өрістері бар оқиғалар. 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 }

Тапсырманы іске қосудың теңшелетін кілті

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

15) Қауіпсіздік және сәйкестік

Аудит: Пайдаланушы шағымдарын («Маған Лимада 23:00 дейін уәде етілді») серверлік хронологиямен келісу үшін екі уақыт проекциясын (UTC және жергілікті) сақтаңыз.
Реттеуіш: есепті кезеңдер талап етілетін аймақтарда қалыптастырылады (салықтар, жауапты ойын лимиттері, «сағат бойынша» маркетингтік шектеулер).
Құпиялылық: сағат белдеуі - жеке баптаулар, бірақ деректерді дәл сәйкестендірмейтін; ортақ құпиялылық саясаты аясында өңдеңіз.

Қорытынды

«Уақытқа сезімталдық» - бұл күн форматы туралы емес, жауапкершіліктің архитектуралық шектері туралы: қайда сақтау, қайда өзгерту, қалай жоспарлау және дұрыстығын қалай дәлелдеу. UTC деңгейіндегі біріздендіру, айқын IANA аймақтары, сауатты жоспарлаушылар, қосарлы таймстемптер және монотонды сағаттар уақытты тосын оқиғалар көзінен болжамды инфрақұрылымдық сервиске айналдырады.

• GeoDNS және гео-бағыттау; Жүктемені теңгеру; Уақыттағы оқиғалардың байқалуы; Cron-паттерндер және кестелерді материалдандыру; Өңірлік шектеулер және жергілікті есептік тәуліктер.