ugrás a tartalomhoz

Dátum-idő típusok

Pepita · 2013. Feb. 1. (P), 13.04
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 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.
 
1

Drupal

Poetro · 2013. Feb. 1. (P), 14.19
A Drupal-ban többek között azért használnak 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).

Előfordul tárhelyszolgáltatóknál, hogy a MySql szerver "órája másképp jár"

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.
2

Köszönöm, kérdés

Pepita · 2013. Feb. 1. (P), 14.46
Az egyéni időzóna teljesen logikus, "csak" nem gondoltam rá...
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 MySql NOW() 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?
3

Druppal

Pallosi Péter · 2013. Feb. 2. (Szo), 12.11
Nem vagyok nagyon jártas a druppalban ezért arról véleményt nem tudok mondani.

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.
4

Megoldva

Pepita · 2013. Feb. 2. (Szo), 15.08
Köszi a szándékot, de - hogy is mondjam - a feltett konkrét kérdések egyikét sem válaszoltad meg; ami általánosságokat írtál, azokkal én is tisztában vagyok. De értékelem a szándékod. :)

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. a NOW() é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.