ITMA Hungary

Informatikai képzések vezetőknek

Az óraátállítás hatása az informatikai rendszerekre

2017. október 28. 11:00 - GernerPéter

2000px-end_cest_svg.pngAz október végén esedékes óraátállítás – ellentétben a tavaszi váltással – az informatikában számos esetben kezelendő üzemeltetési problémát okoz és emberi beavatkozást igényel számos informatikai rendszernél. Ennek oka, hogy az ősszel egy órával vissza, míg tavasszal egy órával előre állítják az időt. Az előre módosuló időt könnyen le tudják kezelni az informatikai rendszerek, de az őszi óra visszaállítás odafigyelést igényel.

Hogyan kezelik az időt az informatikai rendszerek?

Az informatikai rendszerek megbízható működése és integritása nagyban függ a pontos időtől. Néhány informatikai probléma mellett főleg az időzónák, a vallások és kultúrák időszámításai, a dátumformátumok és a különböző időpontokban történő óraátállítások jelentősen megbonyolítják az idő kezelését az informatikában.

 Az UTC és a szökőmásodperc

Az egyezményes koordinált világidő (UTC) az a hivatkozási időzóna, amelyhez a Föld többi időzónáját viszonyítják, és ez a koordinált világidő a modern informatikai rendszerek elsődleges standardja is.

Az UTC nagy előnye, hogy egységes és szinkronizált időpontok használatát teszi lehetővé a Föld bármely számítógépén, és kezeli a Föld lassuló mozgásából adódó időkorrekció, az 1-2 évente előforduló 61. másodperc beiktatását is. Erre legutóbb 2017 elején került sor, pontosabban Magyarországon 2017. január elsején, 00:59:60 másodperckor, amikor egy perc 61 másodpercig tartott az informatikai rendszerekben.

Az UTC-vel az informatikai rendszerek „feltűnés nélkül”, egy másodpercnél kisebb eltéréssel követik az egyezményes világidőt.

Az idővel kapcsolatos informatikai probléma és bonyodalom nem technikai, hanem a felhasználói szokásokból és kultúrából következik.

Az időzónák, a naptárak és dátumformák, na meg az óraátállítás

Ha nem lennének különböző időzónák, és azokban felhasználók, időszámítások és kultúrák, az idő kezelése az informatikában a rendszerek szinkronizációjából és a néhány évente előforduló 61. másodperc beiktatásából álló unalmas technikai kérdés volna

timezonemapdateline.jpg

Az idővel kapcsolatos informatikai problémák kezelésére kétféle időt különböztetünk meg.

  • Fizikai vagy rendszeridő, ahogy a fizikában is, az idő egy-egy pontja. Ezt az időt jól lehet UTC-ben kifejezni, és ez számít standardnak az informatikai infrastruktúrában. Nem ezt az időt látják azonban a felhasználók, mert a rendszeridő nem fejezi ki a hétköznapi időt.
  • Felhasználói vagy hétköznapi idő: ahogy látjuk az időt, annak országonként megszokott formátumával, időzónájával, kultúrák időszámításaival, naptáraival és óraátállításaival. Informatikai szempontból a felhasználói idő kezelése bonyolult, de mivel ezt használjuk, ezt kell megoldani.

Az idő kezelése az informatikában

Az időzónát és a téli/nyári időszámítást az UTC-hez viszonyított eltéréssel fejezzük ki: UTC+1 óra a téli (normál) európai időzóna. UTC+2 óra az európai nyári időszámítás, de vannak nem egész órás eltérést igénylő időzónák is.

A nyári és téli időszámítás közti váltás az UTC-hez viszonyított eltérést változtatja meg. Hogy még bonyolultabb legyen, nem minden országban történik ugyanakkor az óraátállítás, bár Európa ebben példásan egységes. Az UTC-től való eltérés tehát időnként megváltozik, vagy jogszabályok változása, vagy az óraátállítás miatt.

Az időzónákat és időszámításokat leíró szabályokat és változásokat időzóna-adatbázisokban tartják nyilván (Microsoft https://support.microsoft.com/en-us/gp/cp_dst és IANA https://www.iana.org/time-zones ), gyakori frissítésekkel (https://blogs.technet.microsoft.com/dst2007/).

Az egyes kultúrák naptárai, például a Gergely-naptár, az iszlám vagy zsidó időszámítás, a különböző dátumformátumok beállítása operációs rendszerenként eltérő támogatás és gyakorlat alakult ki. Informatikai üzemeltetői szempontból a naptárak beállítása általában nem problémás, mert elég a telepítéskor beállítani, utána nem változnak rendszeresen. Felhasználóknak ugyanakkor gyakori és kedvenc problémája a dátumformátumok okozta kellemetlenség, vagy a fejlesztők rémálma például egy jövőbeni dátum minden szempontból (időzóna, időszámítások, óraátállítások, dátumformátumok, karbantartási és támogatási gyakorlat, felhasználói élmény...) korrekt kezelése.

A pontos idő beállítása a számítógépeken, általában rutin üzemeltetői feladat, ehhez pontos és gyors eléréssel rendelkező időszerverek állnak rendelkezésre, csak Magyarországra 60-nál több ilyen szerver használható. (http://www.pool.ntp.org/zone/hu)

screenshot-2017-10-28_pool_ntp_org_ntp_servers_in_hungary_hu_pool_ntp_org.png

Az informatikai rendszerekben az adatok integritására és időbeli szinkronizáltságára azonban az őszi óraátállítás kockázatot és feladatot jelent az üzemeltetőknek.

Az óraátállítás, mint informatikai probléma

Ha a számítógépek egységesen a koordinált világidőt (UTC) használják, ha rendszeresen és pontosan szinkronizálnak a pontos időt szolgáltató szerverekhez és időzóna-adatbázisokhoz, és ha az alkalmazások csak UTC-ben tárolnák az időre vonatkozó adatokat, és ha csak a felhasználók felé jelenítenék meg az adott időzónában, naptárban és dátumformában az időt, és ha ...

Világos, hogy az idő megváltozásának pontos kezeléséhez számos feltétel tartozik, és köztük mindig van 1-2, amely nem teljesül, vagy túl bonyolult lenne megoldani, hogy mind teljesüljön. És van, hogy nem is oldható meg korrekten a probléma. Gondoljunk bele, egy jövőbeni dátum, amely rögzítése után is megváltozhat a nyári időszámítás időpontja, de több időzónában és országban kell koherensen megjelenjen, milyen bonyolult problémát okozhat a fejlesztőknek. Hasonló problémák miatt sok fontos alkalmazás nem az ideális módon kezeli az időt, és cserébe az egyszerűbb kódért bonyolultabb üzemeltetési eljárások szükségesek.

Az őszi óraátállítás pontosan azt jelenti, hogy vasárnap hajnali három órakor az idő egy órát visszalép, és 3:00 helyett újra 2:00 lesz. Ennek a váltásnak komoly következményei vannak az informatikában.

dst_spring_forward.png

dst_fall_back.png

  • Adatintegritás: a 2:00 és 3:00 közti óra kétszer fordul elő a rendszerekben, egyszer a nyári, egyszer a téli idő szerint. Időzített eljárások esetleg kétszer futhatnak le, vagy elromolhat a kronológia: a valóságban egy új, az éppen érvénybe lépett téli időben 2:10-kor létrejött fájl fél órával később jön létre egy régi nyári 2:40-es időbélyeggel rendelkező fájlnál, de a téli időben 2:10-kor keletkezett fájl korábbi időbélyeggel rendelkezik, mint a másik, a nyári időben 2:40-kor létrejött fájl.
  • Hibajelzések: azokban a szoftverekben, ahol az időtől függő számítások vannak, az adatok integritása és visszaállíthatósága sok ezekben az időponton múlik. Ha egy ilyen függvény azt érzékeli, hogy az idő nem folytonos, hanem hirtelen egy órával visszaállítódik, hibát kell, hogy jelezzen, melyek hatását kezelni kell az üzemeltetőknek.

Informatikai megoldások az őszi óraátállításra

Amennyiben az üzemeltetők tudják, hogy egy alkalmazásban vagy informatikai rendszerben nem megoldott vagy nem megoldható az dupla óra jelentette probléma, egyszerűen leállítják a rendszereket erre az időtartamra.

Az egyik elterjedt megoldás, hogy az őszi óraátállításkor legalább két órára lekapcsolják az informatikai rendszereket. Ez a legegyszerűbb változat, ez okozza a legkisebb hibalehetőséget az operációs rendszer és az alkalmazások időkezelésében.

Értesítjük, hogy a Kormányzati Portálhoz és az Ügyfélkapuhoz kapcsolódóan 2017.10.28-án (szombat) 13:00 óra és 21:00 óra között karbantartást végzünk. Ezen időszak alatt a Kormányzati Portál, valamint az Ügyfélkapu azonosítással működő szolgáltatások nem lesznek elérhetőek. Szíves megértését és türelmét köszönjük!

Azonban nem lehet minden rendszer esetében megtenni, hogy legalább két órát egyszerre leáll az informatika. A hosszú leállást jelentő probléma csökkentésére létezik egy rövidebb, egy csak egy órás leállást igénylő eljárás is, ahol már az operációs rendszer és az adott alkalmazások időkezelésének pontos ismeretében megtervezhető egy 60+ perces leállással járó átállás.

Harmadik lehetőség, amikor egy alkalmazás nem tudja kezelni a dupla órát, hogy a problémás két óra alatt az operációs rendszer a felére lassítja az idő futását a számítógép órájában, így a két óra (nyári időben 2:00 és 4:00 között) egy órának látszik az adatokban.

Így vagy úgy, az informatika megtanulta kezelni az őszi óraátállítás jelentette problémákat, de számos informatikusnak ez az óraátállítás a megszokottnál több munkát jelent ezen a napon, és kimaradnak az óraátállítás jelentette plusz egy óra alvásból is.

További olvasnivalók angolul

https://blog.cdemi.io/time-zones-and-daylight-savings-in-your-infrastructure-and-applications/

http://www.expertum.net/sap-alerts/change-to-winter-time-2016

https://www.timeanddate.com/time/map/about

http://binary-notes.ru/datetime-pitfalls/

https://en.wikipedia.org/wiki/Daylight_saving_time

 

13 komment

A bejegyzés trackback címe:

http://itma.blog.hu/api/trackback/id/tr7913111464

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

maxval bircaman bácsi szeredőci mélyelemző · http://bircahang.org 2017.10.29. 13:09:10

A brüsszelita elnyomás egyik eleme az órabaszogatás.

Kurt úrfi teutonordikus vezértroll 2017.10.29. 14:13:35

Remek dolog ez ilyenkor, mert jelenthetem a vezetőségnek, hogy sikerült javítanom a feldolgozásokon. Egy óra alatt lement, ami eddig kettő volt.

Mr. Cobb 2017.10.29. 14:13:35

Nem is lenne értelme ilyen problémáról beszélni, ha a fejlesztők egyszerűen UTC-ben tárolnának minden időadatot. Soha nem lenne ütközés...

Kovacs Nocraft Jozsefne 2017.10.29. 14:17:40

@maxval bircaman bácsi szeredőci mélyelemző:

Magyarországon 1980 óta megszakítás nélkül megy az óraállítgatás. Előtte is volt, de szünetekkel. Vagyis ez éppen nem az EU bűne, de az már igen, hogy jó eséllyel soha nem lehet megszabadulni az állítgatástól, mert közös döntést igényel.

maxval bircaman bácsi szeredőci mélyeIemző · http://bircahang.org 2017.10.29. 15:44:03

@Kovacs Nocraft Jozsefne: A kapitalizmus már ezzel is igyekezett bomlasztani az orosz nép testvéreit.

midnight coder 2017.10.29. 17:07:06

@Mr. Cobb: Általában a profibb rendszerek, különösen a multik rendszerei amiket több országban is használnak, abban tartják.

midnight coder 2017.10.29. 17:09:14

@maxval bircaman bácsi szeredőci mélyeIemző: Mondjuk mi soha nem voltunk az orosz nép testvérei. Ezzel együtt valóban szarhatna egy szép, kövér farfekvéses sünit aki ezt az óraállítgatásos mókát anno kitalálta. Mondjuk minden héten egyet.

munkanélküli informatikus 2017.10.29. 17:17:58

Sokféle népségnek nem tetszik az óraállítgatás, de biztos vagyok abban, hogy az informatikusok az élbolyban vannak :)

qwertzu 2017.10.29. 18:55:35

WTF?
Ha ez gondot okozhat, akkor minden időpontot és eseményt UTCben tárolunk/vezérlünk. Ez nem valami bonyolult dolog, teljesen alap.

Kovacs Nocraft Jozsefne 2017.10.29. 19:04:43

@qwertzu:

Na és mit csinálsz akkor, ha 2017. november 10-én a user beírja azt a dátum/időt, hogy 2017. október 29. 02:30? Ezt hogyan fordítod le UTC-re? :)

Egyébként abszolút jogos, amit írsz, de ehhez az alapoktól új oprendszereket és programokat kellene írni. Viszont az oprendszerek és a programok is egyfajta szerves fejlődésen mennek át. Pl. a Linux - és más oprendszerek - legmélyén több évtizedes rutinok működnek, amelyek bizony előre kiszámíthatatlan galibákat okoznak. De amikor valaki új oprendszert ír, ő is változatlanul át fogja venni pl. a kommunikációs protokollok rutinjait, akár azért is, mert jogvédettek, nem is férhet hozzá a forráskódhoz. S ez csak egy példa, talán ebből is kiviláglik a lényeg.

Mr. Cobb 2017.10.29. 20:45:02

Írtam már programot saját célra, egyszerű log generálást. Eszembe se jutott más formában tárolni az időbélyegzőt. Körülnéztem több fórumon is (stackoverflow stb.), másnak se nagyon. Csak a 40 évvel ezelőtt végzett, lyukkártyán nevelkedett "senior" fejlesztők követnek el ilyen dolgokat...

rushman 2017.11.03. 20:17:28

@Kovacs Nocraft Jozsefne: Neked talán nem megy? Ez egy időpont a tér-idő-kontinuumban, nem olyan nehéz. ;P
A kívánt dolog 2017. október 29. 02:30-kor meg fog történni. Mondjuk a 2017. október 29. 00:00-kor érvényes időszámítás szerint. Nyilván, ha a megrendelőnek van egy olyan aberrációja, hogy az időpont rögzítésekor el is kívánja dönte(t)ni, melyik időszámítás szerint kell értelmezni az általa szolgáltatott adatot, akkor meg lehet oldani. Pain in the ass, de megsúgom, 99,9999%, hogy nincs neki ilyen.
Az, hogy adminisztratív eszközökkel meghágják az idő folyamát, nekünk még nem feltétlenül belemennünk az idióta kis játékaikba. Attól, hogy nem látjuk, még van kanál. :)

Kovacs Nocraft Jozsefne 2017.11.03. 21:42:50

@rushman:

Húha, hogy te milyen okos vagy!!!