Programozásilag igen, ez a három van. De funcionálisan, a valódi nyújtott üzleti szolgáltatás tekintetében nem ez a lényeg. Hanem hogy az user mire számít, és hogy a funkció mikor működik elvárás szerint.

Az offsetesnek nem örülünk, de nem az a baj hogy legörbül a szánk széle, hanem hogy egy csomó mindent lehetetlen vele precízen megvalósítani.

Mondok egy példát:

2030 November harmadika 15:00 az hány óra múlva lesz? A helyes válasz: nem tudjuk! Ugyanis lehet hogy addigra eltörlik a óraátállítást, lehet hogy nem, lehet hogy a nyárit tartják meg, lehet hogy a télit. Ha megtartják is, nem tudjuk mikor lesz az őszi állítás, mert még nem dőlt el, és ha eldőlt, akkor is változhat.

Mindezt a bizonytalanságot nem tudod lekódolni. Ha az a kérdés hogy 2030 November harmadika 15:00 Europe/Budapest hány óra múlva lesz, akkor legalább meg tudom mondani, hogy a jelenlegi állás szerint mennyi. És elég lesz a dátum library-t upgradelni rendszeresen ahhoz, hogy a jövőben megjelenjenek benne a megismert politikai-jogi változások.

Ezért a design során fel kell mérni, hogy hol is van valójában a naptár és időzóna implementáció. A mi kódunkba húztunk be egy libet, és nekünk fog kelleni frissítést kiadni hogy bejöjjön a változás (és a lib gazdája kell frissítse a libet), vagy a runtime része a lib, és az ops teamnek kell a runtime-t (pl jdk) up to date tartani, vagy az oprendszer része a lib, és azon múlik hogy patchelik-e rendesen, vagy egy külső szolgáltatás adja (pl az adatbázisszerver) és azzal kell törődni hogy az patchelve legyen rendesen.