Aplikacja i uzytkownicy z roznych stref czasowych Opcje

[nospor]

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.

[rocktech.pl]

Witam.

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

STREFA gdzie będzie podane z jakiej strefy szlo zapytanie? np "+02:00", "-11:00".

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

[nospor]

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

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

[nospor]

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

[!*!]

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

[nospor]

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? (IMG:style_emoticons/default/wink.gif) Na serwerze w grudniu będzie czas zimowy i wtedy zostanie to wykonane o tej godzinie jaką ktoś zaplanował.

[nospor]

Jeszcze nie jestem przekonany (IMG:style_emoticons/default/smile.gif)

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?

[!*!]

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?

Po co chcesz zmieniać czas z warszawskiego na warszawski? (IMG:style_emoticons/default/wink.gif) 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.

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 ?

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

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?

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 (IMG:style_emoticons/default/wink.gif) 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 (IMG:style_emoticons/default/biggrin.gif) podejrzewam że masz coś podobnego.

[nospor]

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 (IMG:style_emoticons/default/smile.gif) 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?

[nospor]

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

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?

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 (IMG:style_emoticons/default/smile.gif)

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

[!*!]

Google zwraca dane w takiej postaci: 2013-10-11T13:30:00.000+02:00.

A jak usuniesz te +02:00?

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

[hind]

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

[nospor]

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

Powód edycji: [nospor]:

[!*!]

@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 ;)

[nospor]

@nospor - cron chyba będzie wiedział na jakim jest serwerze w jakiej strefie czasowej (IMG:style_emoticons/default/wink.gif)

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 (IMG:style_emoticons/default/smile.gif)

[!*!]

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 (IMG:style_emoticons/default/smile.gif)

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

[nospor]

Byc moze (IMG:style_emoticons/default/smile.gif)

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ć?

[pyro]

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.

[rocktech.pl]

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

[nospor]

@pyro tak, byla o tym mowa (IMG:style_emoticons/default/smile.gif)

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

[!*!]

Ogólnie zastnawiam sie czy konwertowanie wszystkiego na jedna strefe, powiedzmy na te Europe/Warsaw,

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

[nospor]

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

[rocktech.pl]

W Twoim pomysle zamiast do Europe/Warsaw to konwersja jest do Zulu

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

i wczesniej kazales trzymac date jako timestamp ale to ma ograniczenie do 2038 roku

Co do problemu roku 2038 to chyba inny temat (IMG:style_emoticons/default/smile.gif)

[!*!]

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.

[nospor]

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

Moj umysl tego nie ogarnia i nadal nie wiem dlaczego (IMG:style_emoticons/default/sad.gif)

Co do problemu roku 2038 to chyba inny temat

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.

[!*!]

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

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.

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.

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.

Ten post edytował !*! 16.10.2013, 12:10:58

[nospor]

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.

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?

Powód edycji: [nospor]:

[!*!]

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.

[nospor]

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 (IMG:style_emoticons/default/smile.gif)

[!*!]

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 ;)

[nospor]

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.

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.

Dlaczego czas X jest lepszy od zapisu do czasu serwera? Bo miejsce serwera może się zmienić, a pobyt X nie.

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.

[!*!]

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.

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.

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.

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 ;)

Ten post edytował !*! 16.10.2013, 13:37:16

[rocktech.pl]

Moj umysl tego nie ogarnia i nadal nie wiem dlaczego (IMG:style_emoticons/default/sad.gif)

No nie wiem. nie chcialbym zaraz znowu wszystkiego poprawiac.

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/

[nospor]

Będąc X wysyłasz wiadomość o 10:00 konwertujesz to na 16:00 czasu serwera

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 (IMG:style_emoticons/default/smile.gif)

[!*!]

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.

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.

[hind]

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

[nospor]

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

Jak użytkownik zmieni strefę, to nowe wiadomości są zapisane wedle niej, a stare zależą od Twojej wyobraźni (IMG:style_emoticons/default/wink.gif) 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.

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 (IMG:style_emoticons/default/tongue.gif)

@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 (IMG:style_emoticons/default/smile.gif)

[!*!]

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

[nospor]

!*! 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 (IMG:style_emoticons/default/smile.gif)

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 (IMG:style_emoticons/default/wink.gif)

[emp]

@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 (IMG:style_emoticons/default/smile.gif)

January blefuje a Dusia ma rację

Ja wam to pochytam jak nie ogarniacie ;)

Ten post edytował emp 17.10.2013, 08:27:50

[!*!]

[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?

[nospor]

@emp dorzuć kisiel... co tak na sucho po mordach bedziemy sie lac.... (IMG:style_emoticons/default/wink.gif)

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

Ten post edytował !*! 17.10.2013, 08:33:54

[nospor]

!*! 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 (IMG:style_emoticons/default/smile.gif)

[!*!]

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

[nospor]

!*! (IMG:style_emoticons/default/smile.gif) Dziekuje ci za wklad w dyskusję, naprawde z niej skorzystalem, pomimo ze myslalem ze mowisz o czyms innym na poczatku (IMG:style_emoticons/default/smile.gif) 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 (IMG:style_emoticons/default/smile.gif)

[!*!]

Popieram, tylko podaj jeszcze kod jak możesz w Twojej wersji z "+02:00" itd. Jak opiera się o tę samą klasę.

[nospor]

Nie bardzo rozumiem.... Jaki kod?

!*! Ostatnia proba z mojej strony przekonania Cię (IMG:style_emoticons/default/smile.gif) Weź na przykład jak działa google calendar:
ustaw mu wydarzenie na daną godzine, zapisz. Potem zmień strefe kalendarza i spojrz na godzine wydarzenia. Zmienila sie, dostosowala sie do aktualnej strefy. Czyli jak w Denver byla 10:00 a strefe kalendarza zmieniles na Warszawe, to pojawi sie 18:00 a nie nadal 10:00 jak ciagle twierdzisz. Kalendarz dostosowal sie do strefy dzieki czemu wiem, o ktorej mam spotkanie w tej wlasnie strefie. Nie ineresuje mnie teraz, ze w mojej strefie byla to 10:00. Ja teraz jestem w Warszawie i mnie interesuje czas spotkania w strefie warszawskiej, gdyz w przeciwnym wypadku przyjde na zlą godzine a zarazem zapewne omine cale spotkanie.

Zauwaz, ze nie mowimy tu o zmianie czasu letniego na zimowy w danej strefie. W przypadku zmiany czasu letniego na zimowy (i na odwrot) faktycznie, jak sie umowilem na 10:00 to i nadal mam to spotkanie o 10:00 niezaleznie czy sie zmienil czas letni/zimowy czy nie. (IMG:style_emoticons/default/smile.gif)

[buliq]

[PHP] pobierz, plaintext 
<?php
//X jest w Denver, spotkanie o 10 jego czasu
$date = '2013-10-10 10:00:00';
 
//Strefa czasowa X
$zoneX = 'America/Denver';
//Strefa czasowa Y
$zoneY = 'Europe/Warsaw';
 
// czas X, czyli w denver
$timeX = new DateTime($date, new DateTimeZone($zoneX));
 
// czas jest ten sam, zmienia się strefa czasowa
$timeY = clone $timeX;
$timeY->setTimeZone(new DateTimeZone($zoneY));
 
echo $timeX->format('Y-m-d H:i:s')."\n";//10:00, czas w Denver
echo $timeY->format('Y-m-d H:i:s')."\n";//18:00, czas w Warszawie
[PHP] pobierz, plaintext 

Jeżeli X jest w Denver to zastosuje się do czasu w Denver i w pupie będzie miał czas Warszawski, ale jeżeli już jest w Warszawie to sytuacja jest odwrotna, nie interesuje go że w Denver jest 10, bo patrzy na zegarek i widzi 18.

@!*! zapewne chodzi Ci o to że w Denver nadal jest 10?

[!*!]

@nospor - i tak właśnie działa mój kod jaki napisałem wyżej. Godzina spotkania zgadza się u X i u Y, a jak X wyjdzie to ma poprawną godzinę po zmianie na czas Warszawski, bo tak było ustawione spotkanie.

[nospor]

W warszawie kolesiowi powinna sie pokazywac 18 zas ty ciagle mowilesz ze w warszawie tez mu sie bedzie pokazywac 10 po przestawieniu strefy co notabene jest zgodne z Twoim kodem, ale nie z logiką (IMG:style_emoticons/default/smile.gif) Po przestawieniu strefy na warszawską ma pokazywac 18 a nie 10 jak to ciagle mowisz (IMG:style_emoticons/default/smile.gif)

// 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?

edit down: tak tak, zostawmy to (IMG:style_emoticons/default/smile.gif)

Powód edycji: [nospor]:

[!*!]

Dlatego piszę Ci to od początku. Musisz wiedzieć dla jakiej strefy czasowej ustawiasz spotkanie i w jakiej strefie jesteś. Proste :D Nie da się zjeść i mieć ciastka. Zostawmy to.

[Ghost_78]

Witam Panie i Panów (IMG:style_emoticons/default/smile.gif) .

Wtrace swoje 3 grosze poniewaz widze, ze mam ten sam problem co nospor lub podobny. U mnie sytuacja wyglada tak, ze musze wygenerowac raport (a raczej wiele raportow). W raporcie uzytkownik moze wybrac offset dla czasow w kolumnach. Nie za bardzo chce mi sie przerabiac kazde zapytanie do wszystkich raportow i dodatkowo nie chce mi sie przerabiac wszystkich kontorlerow/widokow (IMG:style_emoticons/default/smile.gif) . Ot taki leniuszek ze mnie (IMG:style_emoticons/default/wink.gif) . Idealnym rozwiazaniem by bylo ustawienie na stale offsetu do zapytania do MySQL'a. W sieci znalazlem cos takiego:

[SQL] pobierz, plaintext 
SET time_zone = '+5:00'
[SQL] pobierz, plaintext 

ale nie chce to dzialac. Nie wiem czy to dokladnie do tego sluzy (IMG:style_emoticons/default/smile.gif) .
Zmiana tego parametru powinna skutkowac zmiana tej zmiennej na czas sessji.

Moje pytanie brzmi: czy da sie to rozwiazac po stronie SQL'a oraz czy trop z ta zmienna jest wlasciwy? (IMG:style_emoticons/default/smile.gif)

Pozdrawiam serokie grono.

[nospor]

Raport masz na mysli poprostu zapytanie do bazy i zrobienie z tego wizualnej prezentacji?
I na stronie poprostu okreslasz o ile ma przesunac daty, ktore zwroci zapytanie?

Jesli na oba pytania jest "TAK" to po co ci zmieniac wszystkie kontrolery? Poprostu w akcji co wyswietlasz raport, dodajesz swoj offset w php do wartosci z bazy.

Jesli odpowiedz to "NIE", to nie zrozumialem o co pytasz (IMG:style_emoticons/default/smile.gif)

[Ghost_78]

Bardzo dobrze zrozumiales (IMG:style_emoticons/default/smile.gif) .

Problem jest z tym, ze raportow mam bardzo duzo a bedzie jeszcze wiecej (IMG:style_emoticons/default/smile.gif) . I tak jak napisales trzeba pozmieniac wszystkie akcje w kontrolerach zeby pokazywalo odpowiednie dane. Poza tym trzeba przebudowac zapytania do bazy bo przeciez pytajac o jakies zestawienie podajac jakis okres czasu (np wczoraj) dla jednego wczoraj to UTC + 2h dla innego UTC + 4h.

Zastanawialem sie nad jakims rozwiazaniem, ktore tak jak napisalem wczesniej - ustawi offset dla danej sesji MySQL i nie dosc ze bedzie zwracalo daty odpowiednio przesuniete to jeszcze bedzie mialo to wplyw na WHERE (IMG:style_emoticons/default/smile.gif) . No i znalazlem to

[SQL] pobierz, plaintext 
SET time_zone ='$offset'
[SQL] pobierz, plaintext 

ale nie dziala (IMG:style_emoticons/default/wink.gif)

[nospor]

set timezone dziala tylko na kolumnach TIMESTAMP. Jesli masz kolumny np. DATETIME to niestety to nie zadziala

No niestety bedziesz musial chyba wszedzie zmieniac. Ale juz jak to bedziesz robil, to napisz tylko sobie odpowiednia klase i potem wywoluj jej metody, by jak kiedys przyjdzie cos znowu zmieniac, nie musial tego robic wszedzie (IMG:style_emoticons/default/smile.gif)

ps:
SET time_zone = '+5:00'
Poprawnym offesetem jest raczej +05:00. No ale nie sprawdzalem czy mysql lyka wersje uproszczoną.

[Ghost_78]

Dzieki serdeczne nospor. Wlasnie doczytalem o tym timestamp.
W moim przypadku chyba latwiej bedzie dodac kolumne typu timestamp (zdaje sobie sprawe z 2038:) ) - mniej zmian mnie czeka. Pomysl z klasa jest bardzo dobry ale raczej na poczatku projektu (IMG:style_emoticons/default/smile.gif) . Poza tym jakos jestem za uzywaniem najprostrzych metod. Dla mnie najlogiczniejszym rozwiazaniem jest ustawienie offsetu w MySQL dla zapytania (IMG:style_emoticons/default/smile.gif) .

Co do uproszczonej wersji offsetu to +5:00 przechodzi bez problemu - sprawdzilem (IMG:style_emoticons/default/wink.gif)

Tak czy owak - dzieki za upewnienie mnie z tym timestamp.

Pozdrawiam (IMG:style_emoticons/default/smile.gif)

[edited]
Wlasnie zaskoczylem ze przeciez moge sobie przestawic na danych kolumnach date_time na timestamp (IMG:style_emoticons/default/wink.gif)

Ten post edytował Ghost_78 18.10.2013, 08:01:16

[BartekN]

Polecam obejrzeć z tego rocznej Confitury http://www.youtube.com/watch?v=zsfEWLGgsEY temat "Krótka historia czasu" fajne uzupełnienie dyskusji w tym temacie (IMG:style_emoticons/default/smile.gif)

Ten post edytował BartekN 18.10.2013, 18:47:00

[Crozin]

1. Strefy czasowe i DST są ogromnym... pierdolnikiem. (IMG:style_emoticons/default/wink.gif) http://www.youtube.com/watch?v=84aWtseb2-4 - szczególnie fragment od 3:50.
2. Problem roku 2038 występuje jedynie w przypadku, gdy timestamp reprezentowany jest przez 32-bitową liczbę, a obecnie już niemal zawsze pracuje się na 64-bitowych maszynach.
3. Nic nie stoi na przeszkodzie by w bazie danych zapisywać w ostateczności zarówno czas UTC jak i czas lokalny - przecież w niczym to nie przeszkadza, a dodatkowy nakład pracy jest znikomy.
4. Można też dać użytkownikowi możliwość wyboru. Przykładowo w kalendarzu, tworząc nowe wydarzenie obok pola wyboru daty można dodać jeszcze checkboksa "local time" - determinowałby on czy chcemy brać pod uwagę możliwą zmianę strefy czasowej.

[!*!]

Polecam obejrzeć z tego rocznej Confitury http://www.youtube.com/watch?v=zsfEWLGgsEY temat "Krótka historia czasu" fajne uzupełnienie dyskusji w tym temacie :)

Teraz się zastanawiam czy biblioteka odpowiedzialna za strefy czasowe w PHP jest aktualna np. w związku z rezygnacją Rosji ze zmiany czasu na letni.

[nospor]

Teraz się zastanawiam czy biblioteka odpowiedzialna za strefy czasowe w PHP jest aktualna np. w związku z rezygnacją Rosji ze zmiany czasu na letni.

Tez sie nad tym zastanawialem:
http://forum.php.pl/index.php?showtopic=22...p;#entry1070399
(IMG:style_emoticons/default/wink.gif)

3. Nic nie stoi na przeszkodzie by w bazie danych zapisywać w ostateczności zarówno czas UTC jak i czas lokalny - przecież w niczym to nie przeszkadza, a dodatkowy nakład pracy jest znikomy.

Tylko czemu to ma sluzyc? Jaka bedzie tego zaleta? Bo tworzyc dla kazdej daty podwojne pola w bazie to potworzy sie cala masa zbedynych pol.

4. Można też dać użytkownikowi możliwość wyboru. Przykładowo w kalendarzu, tworząc nowe wydarzenie obok pola wyboru daty można dodać jeszcze checkboksa "local time" - determinowałby on czy chcemy brać pod uwagę możliwą zmianę strefy czasowej.

Tylko tak czy siak trzeba wowczas trzymac czas dodatkowo w UTC, bo jak potem niby uniwersalnie tworzyc zapytania. Nie da sie.

Polecam obejrzeć z tego rocznej Confitury http://www.youtube.com/watch?v=zsfEWLGgsEY temat "Krótka historia czasu" fajne uzupełnienie dyskusji w tym temacie

Fajnie, dzieki za link (IMG:style_emoticons/default/smile.gif)

[!*!]

@nospor - i jak, po dzisiejszej zmianie czasu, coś Ci się posypało? (IMG:style_emoticons/default/wink.gif)

[nospor]

Nie, wszystko działa (IMG:style_emoticons/default/smile.gif)

Żeby była jasność napiszę jaki ostatecznie mechanizm zastosowalem:

Wszystkie daty do bazy zapisuje do strefy bazowej, czyli do UTC. Danych nie trzymam jako timestamp, tylko w formacie DateTime.
Nie zapisuje przy datach zadnych dodatkowych info o strefie.
Info o strefie zapisane jest w profilu użytkownika i na tej podstawie wyświetlam mu wszelkiego rodzaju daty, konwertujac je ze strefy bazowej do jego aktualnej strefy.
Gdy użytkownik zmieni swoją strefę, to automatycznie wszystkie daty wyświetlają się tak jak trzeba.
Oczywiście wszelkie zmiany czasu letniego na zimowy i na odwrot działają w tym mechaniźmie tak jak trzeba. Po dzisiejszzej zmianie wszystkie czasy wyświetlają się poprawnie.

Dziękuję wszystkim za owocną dyskusję (IMG:style_emoticons/default/smile.gif)