Hejka,
zastanawiam się jak należy zaprojektowac bazę/aplikacje pod kątem użytkowników z różnych stref czasowych.

Załóżmy, że mamy moduł komumunikacji i rozmawia ze sobą dwóch użytkownikow z roznych stref czasowych. W jaki sposób zapisywać czasy wiadomosci w bazie? A na dodatek serwer tez stoi w innej strefie niż ci użytkownicy.
Albo kalendarz i ktos ustawil na wydarzenie powiadomienia 4 godziny przed wydarzeniem. Jak serwer ma pobierac poprawnie wydarzenia z roznych stref i sprawdzac ze wlasnie ma juz pojsc powiadomienie?

Czy moze przy czasie w tabeli dodac jeszcze kolumne STREFA gdzie bedzie podane z jakiej strefy szlo zapytanie? np "+02:00", "-11:00". Tylko wowczas jak pisac zapytanie by bylo optymalnie? A moze jeszcze inaczej do tego podejsc?

Pisał już może ktoś coś takiego i moze podzielić się doświadczeniami w tej materii?

Zapisuj czas serwera + datetime i po stronie użytkownika datetimezone elegancko to wyliczy.

Witam.

Czas trzymaj w "timestampie" (on zawsze jest UTC).

- nigdy nie przechowuje offsetu tylko nazwę strefy czasowej "Europe/Warsaw" unikniesz problemu z DST

@!*! moglbys rozwinac swoją mysl bo chyba nie dokonca zrozumialem Twojej idei?

@rocktech.pl no ale tego timestampa przed zapisem do bazy chyba musze przekonwertowac wpierw do jakies stalej strefy, tak? Przeciez koles ze stanow jak wpisze 15:00 a koles z Polski jak wpisze 15:00 to w bazie nie moze to byc ten sam timestamp, bo to sa zupelnie rozne strefy.

A co do offsetu i DST to mozna przeciez zapisac tak:
dla Polski w czasie letnim mamy +02:00 zas w zimowym +01:00. Pytam sie o to, bo widze teraz jak google zwraca czas wydarzen z kalendarza i on to robi wlasnie przez offset. Stad ten pomysl.

[PHP] pobierz, plaintext 
$timezone = new DateTime('2013-10-16 10:27:33', new DateTimeZone('America/New_York'));
$timezone-> setTimeZone(new DateTimeZone('Europe/Warsaw'));
echo $timezone-> format('Y-m-d H:i:s');
[PHP] pobierz, plaintext 

Czas z USA zamieniasz na odpowiedni w PL. W zależności od zastosowań np. powiadomienia w bazie zapisujesz czas określony przez użytkownika, jego strefę czasową i ewentualnie czas po przeliczeniu, aby łatwiej było na tym działać z automatu.

edycja:

[PHP] pobierz, plaintext 
$date = new DateTime('2013-10-16 10:27:33');
$date-> modify('+4 hour');
echo $date-> format('Y-m-d H:i:s');
[PHP] pobierz, plaintext 

!*! no wlasnie mniej wiecej teraz tak mam jak mowisz. Ale nie jestem przekonany do takiej formy. Watpliwosci zaczely mnie nachodzic podczas synchronizacji z google calendar i zaczalem sie obawiac, czy przypadkiem nie poprzestawiam godzin w kalendarzu google jakiemus amerykancowi, co byloby niedopuszczalne. No i martwią mnie te zmiany czasu letniego/zimowego

Lepiej się nie da, po to min. właśnie powstała ta klasa... Jak chcesz pomylić mu godziny w kalendarzu, skoro masz podany dokładny czas na tacy z uwzględnieniem strefy czasowej. A pobierając pierw czas z google, nie musisz się martwić w jakim formacie jest zapisany bo DateTime przyjmie wszytko.

Ok, skoro wiec w bazie będę zapisywał daty w czasie Europe/Warsaw to ta strefa nie moze sie zmienic, musi to byc zawsze Europe/Warsaw.

Dobra, ale pojawia mi sie kolejny problem z czasem letnim/zimowym. Zalozmy ze ktos wpisuje w kalendarzu wydarzenie na grudzien.

[PHP] pobierz, plaintext 
$timezone = new DateTime('2013-12-16 10:00:00', new DateTimeZone('Europe/Warsaw'));
$timezone-> setTimeZone(new DateTimeZone('Europe/Warsaw'));
echo $timezone-> format('Y-m-d H:i:s'); //!!!!Ta data pojdzie do bazy
[PHP] pobierz, plaintext 

No ale w grudniu mamy czas zimowy, teraz czas letni. Na grudzien zapisujemy godzine 10:00, ale teraz to tak jakby godzina 11:00? Takie szkopuly a w glowie mi mącą

Zostaw czas letni i zimowy bo on nie ma znaczenia. Serwer będzie wiedział która jest godzina, prawda? Na serwerze w grudniu będzie czas zimowy i wtedy zostanie to wykonane o tej godzinie jaką ktoś zaplanował.

Jeszcze nie jestem przekonany

1)
Rozwazmy dokladniej ten przypadek z poprzedniego posta. Koles zapisał date z grudnia o godz 10:00. Czyli w bazie teraz mu sie zapisalo 10:00 i teraz wyswietlajac to z bazy i przekonwertowaniu na Europe/Warsaw wyswietli mi sie 10:00, tak? Tak.
A teraz pojdzmy w przyszlosc i zalozmy ze juz jest grudzien, zmienil sie czas na zimowy. Co teraz mi zwroci data po ustawieniu Europe/Warsaw? Nadal 10:00?

2) Koles napisał wiadomosc teraz w czasie letnim o godzinie 11:00. Minal jakis czas, mamy grudzien (czas zimowy) koles przeglada historie wiadomosci i znalazl tę z 11:00. Pokaze mu ze napisał o 11:00 czy o 10:00 ?

3) Leci synchronizacja z google calendar. Sybchronizacje robi koles z innej strefy czasowej ale akurat w tym momencie, ze u niego jest juz czas zimowy a u mnie na serwerze jest jeszcze czas letni (no bo roznica godzin). Czy w tym momencie nie napsuje mu w godzinach w jego kalendarzu google?

Po co chcesz zmieniać czas z warszawskiego na warszawski? Ale ok, ktoś z USA wpisał 10:00 i to poleciało do bazy, konwertujesz to na PL czyli +6 godzin i mamy 16:00 i jest ok. Zakładamy że zaplanowane zadanie jest na grudzień, godzina 10:00 będzie nadal 10:00 czyli 16:00 w PL, bo nikt nie zmienia czasu jako tako, tylko jest to umowne, i nieprzydatne dziś, tak czy inaczej... serwer wie która jest godzina i u niego w grudniu 10:00 będzie taką samą 10:00 jak w czerwcu.


Patrz wyżej, 11 to 11 bez znaczenia czy w czasie letnim czy zimowym. Bo to że pijesz codziennie kawę o 11, to po zmianie czasu na zimowy i tak będziesz ją pił o 11, tylko w Twojej głowie będzie myśl "ehh a wczoraj BY BYŁA 10".



Właśnie to staram Ci się wyjaśnić, rozpisz to sobie na kardce, bo pisząc te przykłady wyżej też się złapałem na tym że coś jest nie tak ustawiłem godzinę 10 czasu w PL, a miała być w USA i zdziwiłem się że w PL po przeliczeniu mamy już 16 podejrzewam że masz coś podobnego.

Poprostu nie chce mi sie uwierzyc, ze tak prosty mechanizm moze dzialac bez problemu Ciagle sie doszukuje jakiejs luki bo niechce jakiemus klientowi rozpierdzielic kalendarza a potem sie glupio tlumaczyc lub stracic klienta.
Do niedawna nie mialem zastrzezen co do tego, ale jak zaczalem robic te nieszczesna synchronizacje i patrzec w jakiej postaci google zwraca mi dane to zaczalem sie wlasnie zastanawiac....

A w jakiej postaci google zwraca te dane? Nigdy się w to nie bawiłem, mają jakiś ichniejszy format?

Weź inny przykład... Umawiasz się na 12 do urzędu następnego dnia. W nocy został zmieniony czas na zimowy. O której idziesz do urzędu i dlaczego jest to 12?

Google zwraca dane w takiej postaci: 2013-10-11T13:30:00.000+02:00. To jest akurat Polska wiec powinno byc niby +1 a nie +2, ale ze mamy teraz czas letni czyli +1 do przodu wiec jest +02:00. I wlasie sie zastanawialem, czy nie trzymac danych w bazie w takiej wlasnie postaci, ale chyba mysql nie ma chyba typu na cos takiego by ladnie operowac potem na tym w zapytania i warunkach

Tak, to rozumiem. Poprostu mialem watpliwosci czy potem baza mi to poprawnie zwroci... wiem, pewnie durne watpliwosci, testowalem to nawet wczesniej, ale kurka cos mnie naszlo ostatnio i wolalem to omowic na forum

Poza tym, jakbym w bazie zapisywal dane w takiej postaci: 2013-10-11T13:30:00.000+02:00 to bym nie musial sie martwic o to, ze wszystko w bazie ma byc w Europe/Warsaw. Niezaleznie czy baza by miala Europe, America czy cos innego to czas bylby jaki jest

A jak usuniesz te +02:00?



A jakie to ma znaczenie, to tylko zmienna, może być stała przypisana do serwera a nie konkretnych użytkowników, oni mają własne.

@nospor: niedawno przechodziłem przez strefy czasowe/czas letni/zimowy. Przy wykorzystaniu DateTime i DateTimeZone całość sprowadza się do podania daty w formacie ISO (yyyy-mm-dd hh:mm:ss+Offset) a PHP już sobie wszystko sam zrobi tak jak powinno (i dodatkowo zwróci timestamp dla UTC)

No dobra, to moze jeszcze jedna sytuacja:
Koles z innej strefy niz Europe/Warsaw dodal sobie wydarzenie na 16:00 i chce miec powiadomienie o tym na godzine przed. Do bazy po konwersji na Europe/Warsaw wpisalo sie powiedzmy ze to wydarzenie odbedzie sie o 15:00.

No i teraz leci u mnie cron, ktory widzi, ze jest regulka na godzinke przed wyslac powiadomienie i szuka wydarzen, ktore maja byc za godzinke dla tego usera. Tylko ze wg. bazy mamy jeszcze czas letni, a u kolesia juz zimowy (lub na odwrot) przez co koles albo za pozno dostanie powiadomienie albo za wczesnie (za wczesnie to akurat maly problem)

Wiem, ze podane godziny pewnie maja sie nijak do sytuacji zmiany czasy z zimowego na letni czy tez na odwrot, ale chodzili mi o nakreslenie sytuacji. Mozliwa jest taka sytuacja? Chyba tak...

@hind a jak Ty w takim formacie wyliczasz ten czas? Czegoś nie rozumiem... Jeśli ktoś wyśle wiadomość o 15 z USA, serwer będzie w Polsce a użytkownik który ma odebrać wiadomość będzie w Chinach to na co Ci te "+02:00" ?

@nospor - cron chyba będzie wiedział na jakim jest serwerze w jakiej strefie czasowej ;)

No widzisz, nie zalapales idei pytania. Cron wie w jakiej jest strefie, ale na poziomie jednej godziny u crona moze byc czas letni a u kolesia czas zimowy, a tego juz zapytanie wiedziec nie bedzie

Przecież to nie ma znaczenia. Powiadomienia sprawdzane są np. co godzinę i w nich uwzględniasz strefę czasową użytkownika.

Byc moze

Ogólnie zastnawiam sie czy konwertowanie wszystkiego na jedna strefe, powiedzmy na te Europe/Warsaw, czy jest to poprawna praktyka. Przyjmijmy, że to działa poprawnie, co zresztą tutaj udowodniono chyba nie raz, ale czy tak to się robi poprawnie? A może jest jeszcze jakaś metoda, której to sie powinno trzymać?

Cześć,

Sorry, jeśli ktoś już wcześniej to napisał, ale nie czytałem wszystkich postów:

Musisz mieć jakąś datę bazową. Nie jest właściwie istotne jaka. Jest to tylko punkt odniesienia. Załóżmy, że będzie to date_default_timezone_set('Europe/Warsaw');

Jeżeli zapisujesz wszystkie daty np. w bazie danych, to sama data powinna być zapisana w formacie bazowym, a w oddzielnej kolumnie strefa czasowa usera (to tylko przykład dla bazy danych, żeby wiedzieć o co chodzi). Manipulować możesz nimi dowolnie.

Jeżeli pobierzesz datę w jakiś sposób, to jej strefę czasową możesz dowolnie modyfikować (tak jak samą datę), na ten przykład:

[PHP] pobierz, plaintext 
$date->setTimezone(new DateTimeZone('America/Denver'));
[PHP] pobierz, plaintext 

Na niej również możesz działać dowolnie i ją modyfikować (w tym odczytywać strefę czasową). Jak porobisz na niej przeróżne operacje, to wystarczy zmienić timezone na w/w defaultowy.

Hej. Musisz mieć czas Zulu w bazie!


Zawsze możesz przekonwertować UTC do swojej lokalnej strefy, ale nie możesz dokładnie przekonwertować czasu lokalnego do UTC..

@pyro tak, byla o tym mowa

@rocktech ale czy to nie sprowadza sie do tego samego, ze ma byc konwertowany to stalej strefy np. Europe/Warsaw? W Twoim pomysle zamiast do Europe/Warsaw to konwersja jest do Zulu. No i wczesniej kazales trzymac date jako timestamp ale to ma ograniczenie do 2038 roku. Czy moze miales na mysli cos innego?

Ale po co chcesz to konwertować? A co jeśli serwery będą wędrowne, załadowane na ciężarówki, bo kto bogatemu zabroni? I jednego dnia będą w polsce a drugiego w chinach? Wtedy będziesz konwertował wszytko w bazie? Nie. Wystarczy czas użytkownika i jego strefa, a resztę wyliczasz z automatu na bazie strefy serwera którą ustawiasz w php.ini lub przez set_default_timezone() (czy coś podobnego).

!*! to chyba sie nie zrozumielismy... Sadzilem, ze mowisz, ze do bazy mam wkladac zawsze czas w Europe/Warsaw, a dopiero podczas wyswietlanai uzytkownikowi konwertowac go do jego strefy. W takim przypadku rowniez nie ma znaczenia czy serwer jest w chinach a nastepnego dnia w stanach, bo ja wiem, ze w bazie tak czy siak jest w Europe/Warsaw. Nie o tym mowiles caly czas?

Zawsze możesz przekonwertować UTC do swojej lokalnej strefy, ale nie możesz dokładnie przekonwertować czasu lokalnego do UTC! Dlatego.


Co do problemu roku 2038 to chyba inny temat

Emm to był tylko przykład. Strefę możesz zapisać tylko w przypadku powiadomień lub czas jaki wygenerujesz dzięki niej, to już zależy od tego jak zaprojektujesz bazę i crona.

W zasadzie w przypadku powiadomień wystarczy tylko nazwa strefy z jakiej pochodzi użytkownik i cron pociągnie to z automatu tylko dla nich. A w przypadku wiadomości, wystarczy tylko czas jej wysłania, bo użytkownik końcowy i tak będzie miał jej obrobioną wersję przez DateTime na podstawie informacji o nadawcy.

Moj umysl tego nie ogarnia i nadal nie wiem dlaczego

No nie wiem. nie chcialbym zaraz znowu wszystkiego poprawiac.

@!*! czyli wkoncu myslimy o tym samym czy nie?
Bo wg. mego myslenia to zapisujemy w bazie zawsze do Europe/Warsaw a strefe czasową usera zapisuje tylko w jego tabeli w jednym miejscu.
A z tego co napisales ostatnio wynika, ze do bazy zapisujemy czas jaki podal user i jego strefe czasową. Czyli do kazdego pola w kazdej tabeli musi dochodzic jeszcze pole na strefe czasową danej daty.

Nie zawsze, tylko wtedy gdy serwer ma taką a nie inną. Strefa czasowa serwera i strefa czasowa użytkownika. Przy wysyłaniu wiadomości do bazy zapisujesz czas ze strefy użytkownika. Gdy go pobierasz obrabiasz na podstawie strefy serwera lub strefy innego użytkownika.



To zależy w jakim przypadku. Dla powiadomień cron przecież nie będzie działał dla każdego użytkownika z osobna, tylko masowo dla danej strefy, więc można mu to ułatwić zapisując ją w bazie w tabeli powiadomienia, nie ma potrzeby obrabiać tych danych dodatkowo sprawdzając strefę serwera ze strefą użytkownika.

No to to wydaje mi sie juz zupelnie dziwne.....
Wg. tego co mowisz to moge miec w bazie dwa rekordy z takimi datami:
2013-10-16 13:00
oraz
2013-10-16 13:00

Niby dwa takie same czasy, ale nie, bo jedno jest w jednej strefie a drugie w drugiej. By porownac na poziomie (niewazne jak) ze sobą obie daty to musze wpierw przekonwertowac je do tej samej strefy lub jakkolwiek przekonwertowac, by móc je porownac.


Natomiast dotej pory sadzilem, ze mowimy o sytuacji, gdy do bazy zapisujemy juz daty przekonwertowane do tej samej bazowej strefy (co powiedzial @pyro), wowczas nasz daty moga wygladac tak:
2013-10-16 11:00
oraz
2013-10-16 15:00

Są to rozne daty, ale w tej samej strefie wiec na poziomie bazy moge je bez problemu porownywac.
Czy tak nie jest lepiej?

Cały czas mieszasz podejście projektowania dla wiadomości i powiadomień. Dla mnie są to kompletnie różne skrypty i inaczej trzeba do nich podchodzić. Sprecyzuj co jest do czego.

Dla mnie oba zagadnienia sa podobne. Data to data, niezaleznie czy to w kalendarzu, wiadomosci czy dacie utworzenia rekordu.

No ale dobrze, zapomnij wiec o powiadomieniach. Jak wiec teraz proponujesz rozwiazac problem, bo juz sam nie wiem ktora Twoja wersja jest do czego

Wiadomości... X wysyła z USA o 10:00 do Y który jest w PL. W bazie zapisujesz 10:00 bo taka była godzina u X w chwili wysłania wiadomości.
Y odbiera wiadomość i widzi, że X wysłał ją o 16 czasu PL.
Dlaczego czas X jest lepszy od zapisu do czasu serwera? Bo miejsce serwera może się zmienić, a pobyt X nie.
Tym samym jak X wyśle wiadomość o 10 do Y, a Y wyjedzie z PL i będzie gdzie indziej, zawsze będzie miał aktualny czas, będący wyliczony na zasadzie strefy czasowej, tam gdzie aktualnie się znajduje, względem czasu wysłania przez X.
Y nie będzie miał pretensji, że w PL była 17, a jak wyjechał do UK zrobiła się 16, ponieważ w UK jest taka a nie inna strefa i to on musi się dostosować a nie odwrotnie.

W powiadomieniach jest inaczej.

X chce być powiadomiony o 10 czasu USA, czyli swojego. Serwer który jest w PL ma inna strefę, ale to nie ma znaczenia, ponieważ cron sprawdza tylko strefę czasową z jaką zostało zapisane powiadomienie (godzina i strefa X). Czyli aktualny czas serwera + strefa X = sprawdzam czy można już wysłać zawiadomienie.

Oczywiście to proste przykłady, bo jazda zacznie się przy wielu powiadomieniach do wielu użytkowników z różnych stref, ale to już inny temat ;)

Skupmy sie wiec na tym. Czyli w tym przypadku zapisujesz date taka jaka jest u nadawcy. Tak wiec dodajesz jeszcze pole ze strefa przy wiadomosci, czy streffe pobierac bedziesz z danych usera?
Bo jesli dodajesz pole na strefe, to za kazdym razem gdy bedzie gdzie data trzeba od razu dodawac pole ze strefa. Strasznie to rosnie.
Jesli zas korzystac bedziesz ze strefy usera gdzies tam zapisanej, to gdy user zmieni sobie te strefe, to nagle ta data bedzie pokazywac zlą godzine, no chyba ze przy kazdej zmienie strefy przez usera bedziesz konwertowal wbisy wbazie do aktualnej strefy ktora zaznaczyl.

Jesli do bazy bedziesz zapisywal wszystko przekonwertowane do daty bazowej, to rowniez nie ma znaczenia, czy serwer zostal przeniesiony czy nie, bo w wpisy wbazie sie nie zmienily.
Rownie gdy user zmieni w swoich ustawieniach strefe, to rowniez nadal wszystko bedzie ok, bo w bazie wpisy nadal sa w strefie bazowej i zadnen problem przekonwertowac je do aktualnej strefy usera.

Ja caly czas podczas tej rozmowy myslalem ze mowimy o tym wlasnie przypadku co napisalem: daty przed zapisem do bazy so konwertowane do strefy bazowej.

Strefa jest zapisana w danych o użytkowniku. I to z niej jest pobierana i na jej podstawie zapisujesz wiadomość. Jak użytkownik zmieni strefę, to nowe wiadomości są zapisane wedle niej, a stare zależą od Twojej wyobraźni ;) Zmiana godziny w wysłanej wiadomości po tym jak użytkownik zmienił strefę, jest bez sensu. Nie bawiłbym się w kompatybilność wsteczną, a jak już to jest od tego prosta metoda i informacje "+ 3 hour" też idzie zapisać u użytkownika np. jeśli by tego chciał... Choć to bez sensu, patrz post wyżej o wyjeździe do UK.



Będąc X wysyłasz wiadomość o 10:00 konwertujesz to na 16:00 czasu serwera i gdzieś tam sprawdzasz że jest 18:00 u Y tak? Zmieniasz serwer, zamiast 16:00 masz 23:00 i musisz teraz to regulować w dwóch miejscach u X i u Y, zamiast tylko u Y.


Proponuję na tym zakończyć dyskusję, obaj mamy racje, kwestia podejścia. Choć zaraz przyjdzie ktoś kto zna się lepiej na MySQL i napisze parę regułek zamiatając temat ;)

Mój tez tego nie ogarnia. Chodzi o to, że nie znasz zawsze offsetu w stosunku do daty GMT.
Wyskrobałem taki przykład do analizy:
(kod raczej samowytłumaczalny)

[PHP] pobierz, plaintext 
$UTCTimeZone = new DateTimeZone('UTC');
$UTCTime = new DateTime('2013-10-27 01:59:59', $UTCTimeZone);
 
$EUWTimeZone = new DateTimeZone('Europe/Warsaw');
$EUWTime = new DateTime('2013-10-27 01:59:59', $EUWTimeZone);
 
echo $UTCTime->getTimezone()->getName().' '.$UTCTime->format('r');
echo PHP_EOL;
echo $EUWTime->getTimezone()->getName().' '.$EUWTime->format('r');
 
$UTCTime->modify('+1 second');
$EUWTime->modify('+1 second');
 
echo PHP_EOL;
echo 'DST';
echo PHP_EOL;
 
echo $UTCTime->getTimezone()->getName().' '.$UTCTime->format('r');
echo PHP_EOL;
echo $EUWTime->getTimezone()->getName().' '.$EUWTime->format('r');
 
echo PHP_EOL;
echo $EUWTime->format('Y-m-d H:i:s');
echo PHP_EOL;
 
 
$EUWTimeNew = new DateTime($EUWTime->format('Y-m-d H:i:s'), $EUWTimeZone);
$EUWTimeNew->setTimezone($UTCTimeZone);
echo $EUWTimeNew->getTimezone()->getName().' '.$EUWTimeNew->format('r');
[PHP] pobierz, plaintext 

Zerknij dodatkowo na:

http://www.thisprogrammingthing.com/2013/t...-aware-website/
https://blog.serverdensity.com/handling-tim...h-php-datetime/

Nie, nie czasu serwera, tylko strefy bazowej. Zakladamy, ze strrefą bazową jest np. Europe/Warsaw i to jest nasza strefa odniesienia, niezaleznie, czy serwer stoi w Ameryce czy w Chinach.

@rocktech.pl na Twoj post spojrze jutro, bo dzis musze juz leciec a tak milo sie gawedzi

To równie dobrze możesz w ogóle nie opierać się na strefach, a losowej liczbie godzin +/-. Po co Ci wyssana z palca wartość bazowa? Jak rozbudujesz skrypt, dobiorą się do tego inni programiści, lub stworzysz dla niego jakieś API, to prędzej Cie powieszą, a Ty po latach będziesz się głowić dlaczego zmiana czasu nie działa pomimo dobrych ustawień na serwerze.

@!*!: W bazie mam datę w UTC (+0) i dopiero podczas prezentacji data jest odpowiednio modyfikowana przez strefę czasową użytkownika.
Serwer też pracuje z datą UTC i dla tego jak ktoś w USA zapisał coś na godzinę 16 , a w Polsce na 11, to dostaną powiadomienia odpowiednio na 16 i 11

!*! CHyba z lekka przesadzasz. Do operowania na datach bedzie API, ktore podaną date bedzie konwertowac albo do zapisu do bazy, albo do odczytu z bazy. I juz. Jesli jakis developer inny bedzie kretynem i nie doczytal, ze w tej apce wymaga sie stosowania API, no to sorki, nic na to nie poradze. A strefa bazowa elimunuje wiele problemow, takich jak ten co go zlales:
Uwazasz, ze nie ma sensu dbac o daty wsteczne.... Nawet jesli mozna by to uznac za prawde, czego i tak nie uznaje, to nie chodzi tu tylko o daty wsteczne, ale i o przyszle, ktorych juz olac nie mozna. Prosty przyklad:

Pan K mieszka sobie w kraju X. Na za miesiac ma miec spotkanie biznesowe w kraju Y na godzine 16 wg. X a na 14 wg.Y. A ze to daleka droga z X do Y to umowil sie, ze pogadaja sobie na skype. Tak wiec dodal w swoim kalendarzu: spotkanie biznesowe ze kims tam na 16:00. No i super. No ale okazalo sie, ze i tak musial pojechac do tego kraju Y jakis tydzien przed spotkaniem. No to sobie pojechal, a ze mial tam troche siedziec to zmienil w systemie strefe czasową na Y, by mu sie w komunikacji daty zgadzaly z obowiazujaca strefa. Gdy przyszedl dzien spotkania, koles patrzy, ze spotkaie ma na 16:00 wiec ma jeszcze trroche czasu. No ale niestety, zonk, bo wg. Twojego systemu czas sie nie zmienil, pomimo zmiany strefy a powinien byl sie zmienic na 14.
Gdyby czas bylk zapisany w strefie bazowej, to bym sie czas automatycznie wyswietlil w aktualnej strefie czyli 14:00

Poza tym problem z developerami tez wystapi u Ciebie, jesli nie bedą do bazy zapisac dat ze strefy usera tylko ze strefy serwera. I tez cie powiesza a Ty po latach bedziesz sie glowic czemu sie zle wyswietla

@rocktech, tak, masz racje. Jako strefe bazową wezmę ZULU, ale nie jako timestamp, tylko normanie DATETIME. To juz nie powinno grac zadnego znaczenia, a ja bardziej preferuje DATETIME

@nospor nadal tego nie ogarniasz, napisz sobie ten przykład w php, a zobaczysz że masz pretensje o 14, że jest 14 ;)

!*! Nie, teraz ty tego nie ogarniasz. Napisalem ci jasny przyklad, a ty nadal go nie rozumiesz. Ty to sobie rozpisz i ogarnij jeszcze raz a nie ja

Koles spotkanie mial o 16:00 w strefie X. Gdy znalazl sie w strefie Y to to spotkaie jest o 14:00. Wg. Twojego zapisu, mimo ze znalazl sie w strefie Y to nadal ma spotkanie o 16:00... i wiesz co? Spoznil sie, bo to Ty nie ogarniasz

January blefuje a Dusia ma rację

Ja wam to pochytam jak nie ogarniacie ;)

[PHP] pobierz, plaintext 
// data spotkania
$date = '2013-10-10 10:00:00';
 
//strefa użytkownika 
$tz = 'America/Denver';
 
$timezone = new DateTime($date, new DateTimeZone($tz));
 
// strefa czasowa kraju w jakim ma się spotkać
$timezone-> setTimeZone(new DateTimeZone('Europe/Warsaw'));
echo $timezone-> format('Y-m-d H:i:s');
// wynik 2013-10-10 18:00:00
 
// X wyjechał do kraju w jakim ma się spotkać tydzień wcześniej i zmienił sobie strefę
$tz = 'Europe/Warsaw';
 
$timezone = new DateTime($date, new DateTimeZone($tz));
$timezone-> setTimeZone(new DateTimeZone('Europe/Warsaw'));
echo $timezone-> format('Y-m-d H:i:s');
// wynik 2013-10-10 10:00:00
[PHP] pobierz, plaintext 

X miał się spotkać o 10, wyjechał zmienił strefę i nadal jest 10. Czyż nie o to chodzi?

@emp dorzuć kisiel... co tak na sucho po mordach bedziemy sie lac....

!*! no wlasnie nie..... raz u Ciebie w Warszawie jest 18:00 a zaraz potem u Ciebie w Warszawie jest 10:00...... Koles w Wawie ma spotkanie o 18:00 a nie o 10:00.... O 10:00 to to spotkanie jest w strefie Denver...

Nie. Data spotkania to 10 w Denver, 18 czasu Polskiego, X jak wyjedzie do PL to ma - 8 godzin to tyłu więc jak zmieni strefę na PL to wyskoczy mu poprawna godzina, czyli 10.
Już Ci o tym pisałem, nie miej pretensji że idziesz do urzędu wcześniej niż musisz. Ustalamy godzinę spotkania na bazie kraju w jakim ma się dobyć.

!*! Koles umowil sie z warszawiakami. Oni na niego czekają na 18:00. U niego zas w tym czasie jest 10:00. Do tej pory wszystko sie zgadza. Ale koles jednak polecial do Warszawy i co? I Twoj kalendarz nadal mu pokazuje 10:00 podczas gdy powinien pokazywac 18:00. To jest Twoja wina a nie jego. Jesli tego nie rozumiesz to dalsza dyskusja nie ma sensu bo ani ja ani Ty nie zmienimy zdania w tej kwestii

Powiedz mi jak u Niego nadal może być 18, skoro zmienił strefę czasową i wyświetlana jest poprawna godzina, przykład zmiany masz w kodzie wyżej.
Nie wklepuj danych na rympał, tylko podstaw to pod strefę czasową miejsca docelowego.

!*! Dziekuje ci za wklad w dyskusję, naprawde z niej skorzystalem, pomimo ze myslalem ze mowisz o czyms innym na poczatku Nie mniej jednak dalsza dyskusja miedzy nami dwoma mija sie z celem, bo kazdy z nas uwaza, ze to drugi sie myli. Pozostanmy wiec na tym etapie i nie spierajmy sie dalej bo to nie ma sensu.

Moze ktos inny nas pogodzi i stwierdzi ze to ja albo ze to Ty masz racje. Albo ze obaj mamy racje, zalezy jak na to patrzec