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

Статус
В этой теме нельзя размещать новые ответы.

CrashX

В прошлом XSiteCMS
Регистрация
6 Июн 2008
Сообщения
682
Реакции
114
собственно есть некоторое приложение в котором проставляется дата посещения, поста и тп


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

Вариант первый
дата задается с 0 часовым поясом
PHP:
date_default_timezone_set('Europe/London');
что я вижу хорошего в этом
-для любого пользователя в любом часовом поясе легко сделать поправку на время, что бы ему было понятно что и во сколько происходит по его местному времени, делаю это руками путем добавления недостающего количества часов

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


Вариант второй
не использовать собственный поправки на часовой пояс, а использовать
только
PHP:
date_default_timezone_set('Europe/London');
и корректировать только с помощью функций часовых поясов,
тут проблема как поймет скрипт что это было записано в том или ином засовом поясе.... при формате даты DateTime

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

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

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

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

Добавлено через 56 секунд
проблема другая определение летнего времени, тк некоторые зоны сдвигаются на 1 час, те у меня сейчас GTM не+6 а +7
 
По-моему твои проблемы решаются на уровне двух функций, что-то типа local_to_global() и global_to_local().

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

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

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