Forum PHP.pl

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.

@!*! 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.

!*! 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.

Ten post edytował !*! 16.10.2013, 09:55:42

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.

Ten post edytował !*! 16.10.2013, 10:52:07

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