|
CodeIgniter i timezones
Imam problem sa konvertovanjem vremena za razlicite zone...
U formi sam koristio CI timezones_menu, i u bazu imam recimo UP35, UP4.... E sad, posto su ove zone korisnika koji ce se registrovati, potrebno je u bazi da kada pravim fakture vreme upisa konvertujem u njihovo vreme... Znaci imao sam upis u 01:15, a korisnik je u +2 onda treba da mu ispisem 03:15... Nisam primetio da CI daje neke olaksice oko ovoga... Mislio sam da koristim php-ovu klasu DateTimeZone ali skripta puca... Verujem da je neko radio sa timezones pa ako moze mala pomoc... tnx |
Imas gmt_to_local() u CI.
|
Najlakse je da cuvas sva vremena u UTC zoni, pa da ga onda konvertujes prilikom prikaza u korisnikovu vremensku zonu. DateTime klasa ti zavrsava posao za to.
|
gmt_to_local(),
ako se ne varam ovo uzima vreme iz neke zone i pretvara u lokalno (serverovo, zavisno u kojoj je zoni podeseno). Meni bas treba suprotno... Vreme u bazi bice u UTC, a ja konvertujem to vreme u druge zone. DateTime, DateTimeZone, cim prosledim kao argument iz baze recimo UP4, skript puca i dobijem samo belu stranu. Mislim da CI ne pravi validne formate (UP4 sam video samo u CI, ne znam ko jos to koristi, tako da DateTimeZone odmah puca), nista nisam uspeo postici. DateTimeZone trazi odredjeni format za unos a izgleda da UP4 i ostali to nisu. Ovo mi je drugi projekat u CI, verovatno ima neka caka a nisam uspeo nista da izguglam. |
Citat:
|
|
DateTimeZone ocekuje zonu u obliku 'Europe/Belgrade', a belezenje zona na osnovu offseta (tipa UP4 za UTC+4) nije bas zgodno, jer kako znas da li korisnik koristi daylight savings? Pa onda imas UP1 kome je trenutni offset 2 sata, kao sto je nama trenutno..
Ja bih ti preporucio da zone konvertujes u standardne nazive zone, da ti bude lako da koristis php funkcije koje rade sa TZ, a uvek iz tog formata mozes da dobijes koji je ofset neke zone ako ti treba zbog konverzije u taj UPx format.. @dinke: Ovo su ok saveti, osim za upotrebu INT polja za datume. Jeste tako jednostavnije jer se izbegne sansa za slucajnu automatsku konverziju, ali je mysql DATETIME tip optimizovan za upite sa BETWEEN, a INT nije, tako da je za ozbiljne stvari bolje koristiti DaTETIME, a onda prilikom inicijalizacije konekcije na bazu uvek poslati Kôd:
SET time_zone='+0:00' |
@ivanhoe, INT je brzi od DATETIME ako se za range koriste prethodno izracunato pocetno i krajnje vreme u sekundama. Pogledaj:
http://stackoverflow.com/questions/4...datetime-index http://gpshumano.blogs.dri.pt/2009/0...g-with-myisam/ http://gpshumano.blogs.dri.pt/2009/0...g-with-innodb/ Da ne pominjemo ustedu od 4 bajta. |
hmm, bas cudno ovo da UNIX_TIMESTAMP() pravi toliku razliku, bilo bi za ocekivati da ce optimizer to da pretvori u INT konstantu pre upita...
Inace, ja sam bas citao ovaj text koji je linkovan na stackoverflow, a cini mi se da sam jos par takvih textova video (ali su verovatno svi koristili UNIX_TIMESTAMP() da generisu integer)... |
@ivanhoe
Posto je bitno i racunanje vremena (zimsko/letnje) onda je majanje mlatiti se sa CI... Jedino resenje je DateTimeZone(). Nisam znao da vode racuna o prelasku na letnje/zimsko racunanje. Hvala svima na odgovorima |
| Vreme je GMT +2. Trenutno vreme je 22:40. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.