Dátum-idő típusok
Sziasztok!
Többször merítettem már ötletet népszerű CMS adatbázisából (főleg Drupal), viszont csak most figyeltem fel arra, hogy nemigen látok bennük
Kérlek, tegyetek egy kis "világosságot homályomba", ez a folt nem hagy nyugodni!
Köszi, Pepita.
■ Többször merítettem már ötletet népszerű CMS adatbázisából (főleg Drupal), viszont csak most figyeltem fel arra, hogy nemigen látok bennük
timestamp, datetime
, stb. mezőket. Mi ennek az oka?- Előfordul tárhelyszolgáltatóknál, hogy a MySql szerver "órája másképp jár", mint a PHP? (...timezone_set, másik szerver, egyéb ok)
- Nem lehet beállítani MySql kapcsolathoz időkezelést? (Én nem tudok rá módot.)
- Valami egész más oka(i) van?
Kérlek, tegyetek egy kis "világosságot homályomba", ez a folt nem hagy nyugodni!
Köszi, Pepita.
Drupal
int
-et, hogy a PHP belső függvényeivel a megfelelő időzónára konvertálják, elvégre minden felhasználó saját időzónát állíthat be, amennyiben belépett (és engedélyezve van ez a szolgáltatás). Azt nem tudom pontosan, hogy az egyes adatbázis-kezelők mennyire kezelik rugalmasan az adatbázisok közötti konverziót, és ezek a metódusok mennyire felelnek meg bármilyen szabványnak, de a Drupal adatbázis-kezelőtől független megvalósításra törekedik, azaz használhatsz mögötte SQLite-ot, PostreSQL-t, vagy Mongo-t, igazából lényegtelen a működés szempontjából (természetesen lehetnek buktatók itt is).Simán előfordulhat, főleg ha a két szolgáltatás nem azonos szerveren vagy időzónában van, vagy mondjuk a rendszergazda hanyagságából nincs szinkronizálva, illetve a DST-hez igazítva.
Köszönöm, kérdés
Az adatbázis-kezelőtől független megvalósítás nekem (saját fejlesztés) nem fontos szempont.
Hanem az már necces, hogy követek-e el hibát akkor, ha egyazon szoftveren (honlapon) belül használok időbélyegre PHP
time()
és MySqlNOW()
fv-t is?Ebből úgy tűnik, hogy igen: hibázok, viszont fontos lenne jó döntést hozzak, mert:
- éles teszt / publikálás előtt van a dolog (közvetlenül);
- ha hiba, akkor sok-sok modelt / adattáblát végig kell túrjak a javításhoz;
- a jövőben nem akarok újra ilyenbe futni.
A helyzet az, hogy a táblákban a mezőtípus mindig
timestamp
, viszont az, hogy honnét kap értéket, ill. egy lekérdezésben mivel hasonlítom össze - mindig attól függ, hogy melyiket gondolom (tudom) gyorsabbnak.Szóval most megetettem magam, vagy nem?
Druppal
A dátum,időpont és idő adattípusok használatának módja és hozzájuk kapcsolódó szolgáltatások szinte minden termékben különböznek.
Az ISO eredeti dátumformátuma a következő négyszámjegyes év,majd az év megfelelő napja.
Néhány op rendszer a rendszeridőt egy hosszú számban tárolja.
A legtöbb adatbázis egy időzónán belül dolgozik.
Általában 24órás időformátumot kéne használnunk a 12 helyett,mert így kevesebb a hibalehetőség.
Mivel a 24órásat nehezebb félreolvasni.
Majdnem minden SQL változat rendelkezik DATE adattípussal,de a hozzájuk tartozó függvények változhatnak.
Megoldva
Végignyálaztam az összes modellem, mellette az adatbázistervvel, és minden insert / update / select műveletnél a PHP date() fv-ével adtam értéket. Így nem használom soha az adatbázisban megadott
DEFAULT CURRENT TIMESTAMP
értéket, ill. aNOW()
és társai MySQL fv-eket. Persze a tutti az lenne, ha a táblákat is módosítanám (kivenném a default-ot), de "nincs kedvem"...Egyébként úgy gondolom, hogy egyáltalán nem baj a timestamp használata, ha nincs egyéni zónaidő ill. többféle motor.