MÁV 🆚 ÓRAÁTÁLLÍTÁS: 0 - 1

> rengeteg adatod lesz ja. lesz. bár én olyan rendszerekhez vagyok szokva, ahol naponta több adat keletkezik, de oké. > amit mind kezelni kell és karban kell tartani (pl menetrend változáskor) egyébként akkor is, ha nem tárolod el az összes indulást egyenként (de egyébként úgyis eltárolod, mert ha bárki mással kell interfészelned, mint a Bivalybasznádon felszálló Kovács Joli néni akkor úgyis egyenként minden indulásról meg kell nekik mondani, hogy ez a vonat akkor most itt ekkor elindul, mert sem a Google Maps, sem az ÖBB nem fogja neked számontartani, hogy a tanszüneti napokon nem induló vonatnak most tanszünet van-e, vagy hogy a szombati munkanapáthelyezés az hétfőnek, pénteknek vagy szombatnak számít-e) szóval ha valami perverz mazochista oknál fogva nem tárolnád el az összes indulást egyenként, akkor minden nem-rendszerszintű változást (pl. ez a vonat most vágányzár miatt mindenhova öt perccel később ér oda) a feltételrendszeredben kell kezelned, ahelyett hogy egy SQL update az adott vonathoz tartozó timestampek módosításával pikk-pakk megoldaná. > De játsszunk el a gondolattal én mondjuk már fejlesztettem olyan rendszert, aminek több időzónát is támogatnia kellett eltérő időpontban váltott DST-vel nem játszásiból is, de persze hogyne, játszunk el. > Csaknem egy sémából, hogy helyi idő szerint 10:00kor indul szombatonként? :) de, abból. nem látom a humor forrását. (hazudok, látom. azt gondolod, hogy "naugyemegmondtam nekemvanigazam". valójában nem, mert továbbra is csak annyit állítok, hogy UTC-ben kellene tárolni az időpontokat.) > Plusz rengeteg teljesen átlagos operationt megbonyolítassz (pl múlt hét másolása jövő hétre - közben volt egy dst váltás - lehet varázsolni megint... ``` Instant newWeeksTime = storedTime.atZone(ZoneId.of(zoneOfLocation)) .plusWeeks(1) .toInstant(); ``` nem látom a varázslatot. illetve ez Java, de feltételezem, hogy ez más nyelvekben is hasonlóan történik. mert a helyzet az, hogy az egész UTC egy 1961-es szabvány, szóval mire a számítógépek világába érkezett és 1970-ben a Unix timestamp számolása elindult már rég az egyetemlegesen elfogadott optimális módja volt az időpontok kezelésének. feltételezve, hogy nem vagy nyugdíjas, mire megszülettél minden ezzel kapcsolatosan felmerült kérdés már megoldott probléma volt. > A vonat helyi idő szerint közlekedik. amúgy nem. a vonat sajnos aszerint közlekedik ahogy a vasutasnak sikerül elindulnia. ez egyébként leginkább attól függ, hogy mi van a (telefonja) órájára írva, ami manapság legtöbbször egy NTP-vel atomidőhöz szinkronizált, majd szegény csórikámnak külön lefordított UTC timestamp. > Ez önmagában elég indok arra, hogy helyi időt tárolj. amúgy nem. még akkor sem lenne, ha aszerint közlekedne. > Való életben létező dolgokat a való életnek megfelelően kell modellezni, minden más bajhoz vezet Na akkor itt álljunk meg egy pillanatra, mert szerintem el kell magyaráznom, hogy mi is az az idő. Mert a valóságban az idő az nem más, mint a téridő egyik dimenziójának, aminek valami megmagyarázhatatlan okból kifolyólag hatása van az entrópia mértékének a változására, a szemlélő sebességéből illetve a környező gravitációs hatásokból adódó Lorentz-transzformációs torzulása. Ez van a való életben. Na ezt nem modellezzük így, mert sok értelme nincs, és amúgy is mindenki felvágná az ereit ha a kibaszott árapály jelenséget is bele kellene számolni a vonat indulásába. Ezzel szemben az elmúlt 6000 évben az a szokás alakult ki, hogy a természet megfigyelésének megfelelően az entrópia változását abban mérjük, hogy periodikusan ismétlődő események "mikor" történnek. Azaz, hogy a nap délben delel. Történelmileg a nap mindig, mindenhol délben delelt, mert ez volt a definíciója. Ezért működött minden napóra. Ez még mindig elég közel van a valósághoz, lehetne is modellezni, tárolhatnánk az adatbázisban a napsugarak beesési szögét. Aztán beütött a modern kor, és pont a vasút megjelenésével először a történelem folyamán előfordult olyan, hogy olyan gyorsan tudtak emberek egyik helyről a másikra eljutni, illetve a már fejlettebb óráiknak köszönhetően "vinni magukkal" az időt, hogy láthatóvá és problémássá vált, hogy aki Londonból érkezett Manchesterbe, annak más az idő mint aki mindig is Manchesterben élt. Úgyhogy kialakultak az időzónák annak modellezésére, hogy bár a valóság az, hogy délben van dél, de nálunk nem délben van dél, mi a Londoni/Pekingi, bármilyen délhez igazodunk. Aztán ezt még megfejeltük az óraátállításokkal, hogy még nagyobb legyen a káosz, de semmiképp sem azért, hogy közelebb kerüljünk a valóság modellezéséhez. Nos ennek a káosznak a tetőpontján kezdtek el olyan rendszereket kidolgozni amik egységesen képesek kezelni az emberek időérzékelését. Ebből lett először a Greenwich Mean Time, majd újabban a Coordinated Universal Time. Szóval nem a valóságot modellezzük, még csak az baszna be. Azt modellezzük, ami bizonyítottan legkevésbé problémás. Nem, ez nem azt jelenti, hogy az UTC-vel nincsenek problémák. Ez azt jelenti, hogy *nagyságrendekkel kevesebb* probléma van vele. > A kiskacsát is kiskacsaként tárolod, nem lúdként [...] Gyakorlatilag azt akarod nekem megmagyarázni, hogy tároljak egy intet stringként Nem. Ha már duck typing, akkor azt akarom megmagyarázni, hogy egy fix időpont tulajdonságaival rendelkezik, és fix időponként kell vele számolni, és fix időpontként hápog, azt fix időpontként tároljuk. De ha már a te hasonlatod... én pont hogy (long) intként tárolnám, te akarsz behozni ilyen csak stringként leírható "minden hét keddjén, kivéve pünkösd után" csavarokat. > de nagyjából erre gondolsz. pontosan. örülök, hogy megérkeztünk. > Igazából ez az a pont, ahol te perzisztálnál még egyet, hogy adatbázisban is láhasd az UTC-t, én nem. nem, én az egész előtt perzisztálnék egyet, hogy minden elve UTC-ben legyen. és nem azért, mert én ilyen nagy számokat szeretek olvasgatni, mint a 1774890420 (sőt a legtöbb adatbázis-kezelő tool a timestampeket lefordítja olvasható dátum-idővé) hanem mert ez biztosítja, hogy amikor egy timestamphez hozzányúlunk, az minden szükséges információt tartalmaz ami az értelmezéséhez szükséges. ezért aztán amíg relativisztikus hatások nem érvényesülnek, az UTC-t csak expliciten szánt szándékkal lehet elbaszni. nekem meg már PTSD-m van az olyan fejlesztőktől akik hely és idő megjelenítése nélkül szórnak bele időpontokat az adatbázisba, mert hát az ő kódjuk ezt tudja kezelni egész addig amíg meg nem változtatják, én meg mikor használnám az adatokat, akkor egy hónapot töltök az adattisztítással, azt túrva, hogy hogyan változott emberünk kódja a kérdéses tárolt időszakban többször, úgy hogy a kód egyébként több időzónában futott és közben mindegyikben volt DST átállás is. > Az ide vezető út meg ugyan az... nem. az az út amit te leírsz gyanúsan hasonlít arra a másikra, amelyik jószándékkal van kikövezve. az én személyes tapasztalatom, hogy az ignoranciával kikövezett út is szenvedéshez vezet.