DateTime() Сравнение и интервалы

Доброго времени суток, вопрос глупый, но четкого ответа как это реализовать я так и не нашел.

Собственно задача:
Полученное время из бд(хранится в timestamp) сравнить с текущим и если оно больше n дней - выполнить определенные действия.

Текущее решение:

-----
То что программа работает, не означает что она написана правильно!

А теперь задумайтесь, какой бред вы написали.
Место и пространство - одно и то же. И не только в физике. Время дня не имеет значения без часового пояса. Кстати, даже с таймзоной зависит от конкретной даты, час может меняться.

Волевым решением вы можете выбрать какую-то одну таймзону и от неё прыгать. Например, всё всегда считать в UTC. Соответственно и все настройки конфигурировать и сохранять в UTC.


Верный результат. Осталось только осмыслить, для какой таймзоны.

-----
PostgreSQL DBA

Мелкий, Абсолютно с Вами согласен, но ситуация в другом, вопрос в том что бы без костылей получить текущее системное время для сравнения с временем из бд(не припомню что бы в тех же плюсах приходилось учазывать timezone для этого, да и time() тоже отлично работает без tz).

Я был бы не против если бы он переводил и системное и полученное из бд время в данную tz в противном случаи получается следующее: время в бд вставляется автоматически значением по умолчанию (CURRENT_TIMESTAMP), а при получении текущего времени для нахождении разности происходит смещение, что дает неверный результат между данными величинами.

upd. откуда мне знать какая tz будет выставлена у сервера? Идея все в UTC - идеальна, вот только как я понял MySQL вставляет текущее системное время не глядя на tz

(Отредактировано автором: 20 Января, 2016 - 09:48:47)

Как и CURRENT_*, CURTIME()

Разве я не тоже самое написал? ему пофиг на tz, он вставляет время в текущем часовом поясе, или я не прав? Как следствие время в БД хранится в неизвестной tz, и как результат я не знаю в какую tz приводить текущий DateTime (кроме костыльного метода привязанного к *nix системам для определения системной tz ничего не встречал), или как получить время в системной tz.

в котором находится сервер. Если это известно, то далее дело техники.

Угу, так и запишем, раньше работали в рамках только одной таймзоны.

std::time - UNIX-time, это UTC0 всегда
std::localtime - текущая таймзона пользователя, от имени которого запущено приложение.
std::gmtime - соответственно, структура даты для UTC0
Как считаются другие таймзоны - честно не помню.


Ага. Потому что UTC0 всегда. unixtime же.
Различие date, strftime с одной стороны и gmdate, gmstrftime в другой. Первые при обработке таймштампа смотрят на локальную таймзону date_default_timezone (не помню, как в ini названа), вторые - только UTC0.


Так и базе скажите, в какой вы таймзоне хотите воспринимать время. В mysql системная переменная time_zone.

-----
PostgreSQL DBA

Хотя не все так однозначно
http://dev[dot]mysql[dot]com/doc/refman/[dot][dot][dot]one-support[dot]html
(Добавление)




http://stackoverflow[dot]com/questio[dot][dot][dot]unctions-use-utc

Благодарю, теперь наконец все встало на свои места)
Речь как раз о неизвестном, в данный момент нет никакого сервера(есть свой локальный для разработки), и в какой tz будет реальный - понятия не имею.

Вы абсолютно правы, тк работать в UTC намного проще и в большинстве случаев достаточно)

Получается тоже не хорошо, но похоже так и придется. Не хорошо потому что если нет доступа к конфигурации mysql придется при каждом соединении отправлять запрос на установку данной переменной(или я ошибаюсь?) так же возникает вопрос: любой ли пользователь может это сделать(нужны ли дополнительные права)?

Благодарю, получается после каждого соединения с БД(в случаи невозможности изменения конфига) отправлять запрос SET time_zone = timezone или есть возможность задать это на этапе соединения используя mysqli(пока бегло пробежался не нашел, пойду еще почитаю)?

ЗЫ: Какое счастье что триггеров с датой нет и не предвидится

(Отредактировано автором: 21 Января, 2016 - 09:27:29)

Сессионную - любой.

-----
PostgreSQL DBA

Спасибо, но в ходе раскопок возникли различные варианты решения:
1. задать значение поля по умолчанию как UTC_TIMESTAMP;
2. Как я понял хранит он все равно в UTC а при запросе конвертирует в соответствии с сессионной tz поэтому мы можем конвертировать сами во запросе: SELECT CONVERT_TZ(created_at, @@session.time_zone, '+00:00');
3. поменять сессионную tz запросом $mysqli->query("SET time_zone = +00:00");

Возможно существуют и другие(при отсутствии прав на изменение конфигов mysql и задание глобальной tz) поэтому вопрос как будет лучше?

поля timestamp - да, mysql хранит в UTC0 и конвертирует к таймзоне time_zone при обращении.
поля datetime - что записали, то будет прочитано вне зависимости от таймзоны.

-----
PostgreSQL DBA

И все же, как лучше поступить? в php без костылей системную tz не получить, как и время в текущей tz, следовательно получаем в UTC. по MySQL вариантам 1 - не нравится тем что похож на извращение хранить не верное время, 2 - не нравится тем что необходим для каждого запроса, а 3ий - необходим для каждого соединения.

Собственно немного поясню почему меня так волнует лишний запрос при каждом соединении с БД: сервис высоконагруженный и если можно обойтись без лишнего запроса к БД или решить данную проблему как-то иначе - был бы рад услышать данные советы.