Ошибка время отличается на 21600 секунд

Когда требуется выполнить синхронизацию с внешним источником данных (например, с 1С), то 1С Битрикс может выдать следующую ошибку: «Время на сервере базы данных отличается от времени на веб-сервере больше, чем на 10 минут». Это означает, что необходимо проверить и настроить правильные временные зоны.

Разберем эту проблему детальнее. Можно выполнить простой фикс (грабли) в виде хука в файле /bitrix/php_interface/after_connect_d7.php
указать принудительно:

$connection->queryExecute("SET LOCAL time_zone='".date('P')."'");

Но мы рекомендуем разобраться детально в причинах проблемы, для этого подключитесь к серверу по SSH и проверьте командой ‘date’ время в операционной системе (здесь и далее мы работаем в CentOS 7.

В консоли мы сначала забекапим временные файлы:

[root@sx ~]# mv /etc/localtime /etc/localtime-backup

потом делаем линк на нужную нам часовую зону:

[root@sx ~]# ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime

И далее проверяем командой ‘date’ корректность нового времени.
Вот как это выглядит в терминале:

[root@sx ~]# mv /etc/localtime /etc/localtime-backup
[root@sx ~]# date
Wed Apr  8 17:19:38 UTC 2020
[root@sx ~]# ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime
[root@sx ~]# date
Wed Apr  8 20:19:46 MSK 2020

Далее подключаемся в MySQL / MariaDB и проверяем тайм-зону командой:

select current_timestamp;

В консоли это выглядит так:

[root@sx ~]# mysql
Welcome to the MariaDB monitor.  Commands end with ; or g.
Your MariaDB connection id is 104506
Server version: 5.5.64-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.

MariaDB [(none)]> select current_timestamp;
+---------------------+
| current_timestamp   |
+---------------------+
| 2020-04-08 20:24:41 |
+---------------------+
1 row in set (0.00 sec)

MariaDB [(none)]> 

Если в MySQL / MariaDB неверное время, то выполняем следующее по определению default_time_zone: идем в /etc/my.cnf (CentOS) или /etc/mysql/my.cnf (Ubuntu) и после:

[root@sx ~] sudo /etc/init.d/mysqld restart

Сложные случаи конфликта во времени в SysConfig

Иногда так происходит, что еще одна отсылка ко времени сервера есть в:

/etc/sysconfig/clock

Вы можете поменять тайм-зону через ‘tzselect’, а в SysConfig, например, может быть прописано: ZONE=America/New_York

Это решается достаточно просто:

[root@sx ~]# vim /etc/sysconfig/clock
ZONE="Europe/Moscow"
UTC=true
ARC=false

Временные зоны в PHP

Сейчас переходим к PHP, здесь тоже может быть нюанс, поэтому смотрим: /etc/php.ini
(из него билдится уже /etc/php.d/bitrixenv.ini) в ini-файле корректируем или добавляем:

timezone =  Europe/Moscow

После изменений в php.ini нужно рестартнуть Апач:

service httpd restart

несколько удваивая ответ @clemens с образцами …

в соответствии с вашим часовым поясом:

t=# set timezone to 'GMT+6';
SET

что ты делаешь:

t=# with c("ct", last_gps_read) as (values('2018-03-21 23:26:07.263931-06'::timestamptz,'2018-03-21 23:26:00.5273'::timestamp))
select ct
, extract(EPOCH from ct)
, last_gps_read
, extract(EPOCH from ct) - extract(EPOCH from last_gps_read)
from c;
              ct               |    date_part     |      last_gps_read       |    ?column?
-------------------------------+------------------+--------------------------+-----------------
 2018-03-21 23:26:07.263931-06 | 1521696367.26393 | 2018-03-21 23:26:00.5273 | 21606.736631155
(1 row)

что ты должен делать:

t=# with c("ct", last_gps_read) as (values('2018-03-21 23:26:07.263931-06'::timestamptz,'2018-03-21 23:26:00.5273'::timestamp))
select ct
, extract(EPOCH from ct)
, last_gps_read
, extract(EPOCH from ct - last_gps_read)
from c;
              ct               |    date_part     |      last_gps_read       | date_part
-------------------------------+------------------+--------------------------+-----------
 2018-03-21 23:26:07.263931-06 | 1521696367.26393 | 2018-03-21 23:26:00.5273 |  6.736631
(1 row)

почему: вы отделяете double precision от double precision и получаете epoch aware of time zone — epoch not aware of timezone. Так что ваш результат ожидаем. И задокументированный. Я предлагаю использовать interval для разделения по временным меткам, независимо от того, известен часовой пояс или нет (так как интервал работает в обоих случаях), а ЗАТЕМ извлекать эпоху из interval. Таким образом, вам не нужно настраивать часовой пояс или унифицировать метку времени с часовым поясом для AT TIME ZONE 'GTM' или чего-то еще …