zapis “2016-12-22T11:18:18+0000” naizgled kaže da se nešto dogodilo u 11 sati i 18 min, ali nije.
Facebook će vratiti gornji zapis vremena za komentar koji se dogodio u 12 sati i 18min.
Kako ispravno dekodirati vrijeme iz gornjeg zapisa? Ne mogu samo dodati 1 sat na 11:18, zato jer kada sam god tako ručno koregirao pomak, to je držalo vodu samo neko vrijeme.
Kužim da se tu radi o nekim vremenskim zonama, ali mi nije baš najjasnije. Ovaj parametar +0000 vjerovatno govori o tom pomaku?
Koji bi općenito bio najispravniji pristup pohrani toga vremena?
Ajmo pretpostaviti da imam korisnike koji su razbacani po svjetu…i sada neka je ovdje 12 sati, a neka je u Americi recimo 20 sati.
Recimo da oba ta korisnika u 12 sati po našem vremenu komentiraju neku objavu, pretpostavljam da onom u Americi treba pisati da su oba komentirali u 20.00, dok našem korisniku će se prikazati da su oba komentirala u 12 sati.
Trazi PHP time format. Ovaj je ako se ne varam ISO-7601 ili nesto u tome stilu (bubam brojke iz glave). PHP to moze pretvoriti u unix timestamp i iz njega mozes formatirat u vrijeme u nepalu ako ti je volja.
Zapisuj vrijeme u timestamp formatu, a ne kao datum, u php ili js ga kasnije mozes formatirati kako zelis. Zapis u bazu ce se dogoditi prema timezone koja je podesena na serveru i sasvim je nebitno koliko je sati kod korisnika jer server to bez dodatnog tvog kemijanja ne moze znati. Dakle ako ja komentiram u 13:45 po lokalnom vremenu, a neko u istom tom trenutku iz amerike komentira, a kod njega je po lokalnom vremenu 20:32, a na serveru je timezone namjestena da je u tom trenutku npr. 08:12 onda ce u bazu biti zapisano da smo obadvoje komentirali u 08:12 sati.
Pohvatah ideju, na serveru definiram timezonu i sve što pohranjujem odnosi se na tu timezonu. Kada neki vremenski zapis šaljem clientu, onda ga moram pretvoriti u odgovrajuću timezonu za browser koji je poslao upit.
Ostaju mi dva pitanja:
Nisam našao kako će PHP znati timezonu browsera. Mislim, jasno mi je da se to može postaviti u cookie…ali ispada po tome da za prvo otvaranje stranice moram pogađati koja je timezona browsera ili formatirati datum tek na client strani (što ne želim)
I dalje mi nije jasno što točno predstavlja ovaj gornji format "2016-12-22T11:18:18+0000"
Koliko vidim ovdje http://php.net/manual/en/function.date.php …tu ima preko nekoliko varijanti/formata kako se označava timezona…i dalje nisam siguran što je to +0000 i koje gotove funkcije parsiraju takav format u nekakv date objekt.
Do sada sam najčešće čitao datum iz baze na način:
SELECT ... ,UNIX_TIMESTAMP(datum) as datum FROM ...
Sada sam to zamislio raditi na način:
SELECT ... ,UNIX_TIMESTAMP(datum) + $GLOBALS[TZN] as datum FROM ...
…gdje će mi $TZN inicijalno biti postavljen kao: ($client_timezone-$server_timezone)*3600
To ne djeluje preveć komplicirano, ali možda se može napraviti elegantnije. Kada bi postojao nekakvi UNIX_TIMESTAMP_FOR_USER_TIMEZONE() ?? …pa se negdje u konekciji na bazu zada koja je user time zona…tako nešto možda?
E to je sad problem za sebe. User ti ne salje svoj timzone vec ga moras ili pitati da ti sam kaze ili koristiti nekakvu metodu IP to geo da saznas od kuda je i prema tome odrediti timezone.
Radi s vremenima u programiranju je vrlo zajebano, zato to malo tko radi. Najcesce stavit jedno vrijeme i napisise da je CET naprimjer. I nek si user sam preracuna kolko je kod njega.
Probaj nac js librarykoji to radi i library koji prema timestampu preracunava u potrebnu zonu. Ak ces sam to pisat, poludit ces.
SELECT ... ,UNIX_TIMESTAMP(datum) + $GLOBALS[TZN] as datum FROM ...
Prvo sam mislio da svagdje gdje sam koristio UNIX_TIMESTAMP() samo dodam korekciju vremena sa $TZN i da je to to…ali ispada da nije. …taj pristup traži previše mozganja kada koregirati čitanje sa $TZN kada ne…
U končnici sam skontao da server praktički nebi trebao čuti za client timezonu … zapravo mi se čini da se nijedna vrijednost datuma nebi trebala “trajno” koregirati po timezoni čak niti na client strani, jedino što treba koregirati je layout datuma kod ispisa.
Što time želim reći …recimo neki komentar ima svoj datum nastanka (timestamp) …i svoj label-datum (onaj datum koji formatirano ispišemo da korisnik vidi kada je komentar nastao.) Koliko mi se čini, ovaj prvu vrijednost (timestamp) je najbolje zadržati u istoj vrijednosti kao što je bila zapisana na serveru …u defaultnoj time zoni, a samo ovo što renderiramo prilagodimo timezoni browsera. Na taj način se izbjegne svašta.
Recimo da želimo taj isti datum koristiti za dočitavanje novih komentara od toga datuma na dalje…onda nam odgovara da tu imamo izvornu vrijednost i s njom formiramo novi SQL upit …dok u situaciji da smo prvotno konvertirali datum kod čitanja iz baze, trebali bi sada opet tu vrijednost konvertirati nazad za taj SQL upit … a kod gradnje SQL upita bi trebali dobro paziti koji UNIX_TIMESTAMP() prilagođavamo sa $TZN koji ne …a da ne govorim da bi neki isti SQL upiti ponekada trebali $TZN korekciju…nekada ne…
…nadalje, sa $TZN treba prilagoditi svaki postojeći SQL upit koji dohavaća datume …dok sa ovim drugim pristupom treba samo prilagoditi funkcije koje služe za renderiranje datuma. A to je u mom slučaju samo jedna funkcija…
Jedina zavrzlama ovog drugog pristupa je da neke datume koje generiramo na serveru, moramo ih nakon generiranja konvertirati u timezonu servera da bi se ispravno ispisali nakon što prođu render funkciju. Ili moramo toj render funkciji dati dodatni naputak kada dolazi datum koji ne treba prilagođavati client timezoni. Ali ovo zapravo nije velika zavrzlama…pošto clientside rijetko generira neki datum, a da se to ne odnosi na trenutno vrijeme…u kojem slučaju se datum niti ne prosljeđuje na server za upis…
Mozda mu MomentJS moze biti od pomoci, jednom sam koristio tako da nisam siguran sta sve moze.Cak ima i MomentJS Timezone http://momentjs.com/timezone/
