Проблема выбора реализации работы с датой

[CrashX]

собственно есть некоторое приложение в котором проставляется дата посещения, поста и тп


но тут я вижу как минимум 2 реализции

Вариант первый
дата задается с 0 часовым поясом

date_default_timezone_set('Europe/London');

что я вижу хорошего в этом
-для любого пользователя в любом часовом поясе легко сделать поправку на время, что бы ему было понятно что и во сколько происходит по его местному времени, делаю это руками путем добавления недостающего количества часов

    if (isset($offset) && $offset != 0):
      //                         mktime (                        $hour                  $min         $sec         $mon         $day         $year)
      $value = $this->parsedate(date('Y-m-d H:i:s', mktime($value['H'] + $offset, $value['I'], $value['S'], $value['M'], $value['D'], $value['Y'])), 0);
    endif;

но теперь минусы,
при занесении данных в СуБД нужно делать обратную поправку
скажем в том случае если пользователь заносит новость или создает событие в своем времени то для занесения в СуБД нужно сделать обратную поправку таких полей для того что бы оно соответствовало его времени
те
я сделал задание на 12-15 скажем отправить письмо, то в 12-15 моего времени (допустим +6) оно должно отправится а по GTM это 6-15...


Вариант второй
не использовать собственный поправки на часовой пояс, а использовать
только

date_default_timezone_set('Europe/London');

и корректировать только с помощью функций часовых поясов,
тут проблема как поймет скрипт что это было записано в том или ином засовом поясе.... при формате даты DateTime

----------
у кого есть идеи по этому вопросу

нужно упростить максимально обращение с датой,
чтобы оно соответствовало нужному времени, и было более менее удобным в обращении

-----
пока пользуюсь вариантом 1, но кажется все же можно избавится от обратной конвертации с форм...

 

[Igor123]

внутри идет работа со временем по гринвичу, а вывод для пользователей делается в зависимости от их часового пояса.

тогда не будет необходимости делать перевод времени с часового пояса пользовался в гринвич.

 

[horpah]

Храни в БД еще таймзону юзера,например в виде "+3", "-1" ... Тогда вообще без разницы какое время вставлять, все легко сможешь рассчитать.

 

[CrashX]

хранить тайм зону и так хнарню это значение offset смешение относительно некоторого времнни, но хочется избавится от правки времени при получении с форм, для заданий, но видимо этого не будет придется обрабатывать как ни жаль

Добавлено через 56 секунд
проблема другая определение летнего времени, тк некоторые зоны сдвигаются на 1 час, те у меня сейчас GTM не+6 а +7

 

[venetu]

По-моему твои проблемы решаются на уровне двух функций, что-то типа local_to_global() и global_to_local().

Внутри приложения все хранить в GMT.

В отображениях, когда ты показываешь системное время конкретному юзеру, переводить в local для этого юзера.

При получении каких-либо данных от юзера, когда ты их фильтруешь (напр. от sql-инъекций) - переводить в global. И все операции с датами (раньше-позже, +10 дней и т.п.) вести в системном времени.

 

[CrashX]

примерно так и делаю)
вопрос о поправке на летнее время пока не придумал)
тк в не в каждом часовом поясе есть, переход на летнее время пока только есть идею о введнении массива, с тайм зонами и возможной поправкой при наступлении даты )

 

[CrashX]

с датой разобрался летнее время просто узнавалось)))

echo date('I', time());