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

Nie bardzo rozumiem.... Jaki kod?

!*! Ostatnia proba z mojej strony przekonania Cię 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.

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

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ą Po przestawieniu strefy na warszawską ma pokazywac 18 a nie 10 jak to ciagle mowisz


edit down: tak tak, zostawmy to

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.

Witam Panie i Panów .

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 . Ot taki leniuszek ze mnie . 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 .
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?

Pozdrawiam serokie grono.

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

Bardzo dobrze zrozumiales .

Problem jest z tym, ze raportow mam bardzo duzo a bedzie jeszcze wiecej . 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 . No i znalazlem to

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

ale nie dziala

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

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

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 . Poza tym jakos jestem za uzywaniem najprostrzych metod. Dla mnie najlogiczniejszym rozwiazaniem jest ustawienie offsetu w MySQL dla zapytania .

Co do uproszczonej wersji offsetu to +5:00 przechodzi bez problemu - sprawdzilem

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

Pozdrawiam

[edited]
Wlasnie zaskoczylem ze przeciez moge sobie przestawic na danych kolumnach date_time na timestamp

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

1. Strefy czasowe i DST są ogromnym... pierdolnikiem. 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.

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


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.


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

Fajnie, dzieki za link

@nospor - i jak, po dzisiejszej zmianie czasu, coś Ci się posypało?

Nie, wszystko działa

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