MySQL: DATE_SUB / DATE_ADD, который отвечает за DST? - PullRequest
Новая
       10

MySQL: DATE_SUB / DATE_ADD, который отвечает за DST?

9 голосов
/ 21 апреля 2011

Возвращает 1 (он же TRUE) 

SELECT DATE_SUB(NOW(), INTERVAL 24*100 HOUR) = DATE_SUB(NOW(), INTERVAL 100 DAY);

100 дней назад, час дня не меняется.Но из-за перехода на летнее время (США) 100 24-часовых периода назад фактически на один час раньше, чем если бы вы сосчитали по дням.Если вышеупомянутое утверждение учитывает DST, оно вернет 0 или FALSE.

Можно ли сказать, что нужно учитывать DST для данного оператора или сеанса?Я бы предпочел не использовать UNIX_TIMESTAMP, так как это отсекает что-либо после 2038 года.

Ответы [ 3 ]

4 голосов
/ 27 февраля 2017

Это на самом деле просто вопрос преобразования в UTC и обратно: 

 CONVERT_TZ(DATE_SUB(CONVERT_TZ(NOW(),@@session.time_zone,'UTC'), INTERVAL 24*100 HOUR),'UTC',@@session.time_zone);

Это предполагает, что у вас есть таблицы часовых поясов, настроенные для использования именованных часовых поясов.Если нет, вы можете использовать «+0: 00» вместо «UTC»

4 голосов
/ 07 сентября 2011

Вам нужно создать пользовательскую функцию, что-то вроде этого. 

DELIMITER $$

CREATE FUNCTION DST(ADatetime DATETIME) RETURNS DATETIME
BEGIN
  DECLARE result DATETIME;
  SET Result = ADatetime;
  IF ADatetime >= startDST AND ADateTime <= endDST THEN 
    result = DATE_SUB(ADatetime, INTERVAL 1 HOUR);
  END IF;
  RETURN result;
END $$

DELIMITER ;
0 голосов
/ 23 сентября 2011

Каким образом обрезание чего-либо после 2038 года станет реальной проблемой, если вы можете быть уверены, что 64-битные целочисленные метки времени будут реализованы везде, по крайней мере, за 20 лет до этого?

Серьезно, в MySQL существует так много проблем с типами datetime / timestamp, что вы должны стараться избегать их, когда это возможно.

Вы храните много дат после 2038 года?

И почему бы не попробовать PostgreSQL, который имеет гораздо более продвинутую поддержку типов?

...