1С УТ: время отличается на 10 часов — что это значит и как исправить

Документы, проводки и записи журналов в 1С:Управление торговлей показывают время на 10 часов раньше или позже фактического — причина почти всегда кроется в настройках часового пояса. Платформа 1С сама по себе не смещает время произвольно: она фиксирует его по данным сервера, клиентского компьютера и информационной базы. Стабильная разница ровно на фиксированное число часов означает, что на одном из участков цепочки «операционная система — СУБД — сервер 1С — клиент» указан неверный часовой пояс, который и нужно найти и исправить.

Число 10 часов встречается не случайно. Типичный сценарий — сервер настроен на UTC или на другой регион, а пользователи работают во Владивостоке (UTC+10) или в другом часовом поясе, и разница между поясом сервера и поясом пользователя как раз составляет десять часов. Другая частая причина — изменение часового пояса сеанса в настройках информационной базы или параметр смещения, заданный администратором.

Прежде чем что-либо менять, важно понять: сдвиг наблюдается только в отображении времени или время физически записано в базу со смещением. От этого зависит, достаточно ли поправить настройки или придётся корректировать уже созданные документы. Ниже разобраны способы диагностики, варианты исправления и меры предосторожности.

Что означает сдвиг времени на 10 часов в 1С

Платформа 1С:Предприятие хранит дату и время документов в едином формате, но отображает их с учётом часового пояса сеанса. Если часовой пояс информационной базы не задан, используется пояс сервера 1С или клиентского компьютера — в зависимости от режима работы. Когда эти настройки расходятся, пользователь видит время, отличающееся от фактического на фиксированную величину.

Сдвиг ровно на 10 часов чаще всего указывает на одну из типовых комбинаций: сервер работает в UTC, а пользователи — в поясе UTC+10; либо сервер находится в одном регионе страны, а рабочие места — в другом, и разница между поясами составляет десять часов. Реже причина в том, что администратор явно установил часовой пояс информационной базы, не совпадающий с реальным расположением пользователей.

Важно отличать сдвиг времени от сдвига даты. Если документы «уезжают» на предыдущий или следующий день, проблема та же самая — просто смещение пересекает границу суток. Это особенно критично для УТ, где от даты документа зависят проведение по регистрам, взаиморасчёты и отчётность.

Как определить, где именно задан неверный пояс

Диагностику начинайте с сравнения трёх значений: текущего времени на сервере 1С (или сервере СУБД), времени на клиентском компьютере и времени, которое показывает 1С в сеансе. Если все три совпадают, но документы записаны со сдвигом — проблема в уже накопленных данных. Если расходятся — ищите, какой уровень настроен неверно.

Проверить часовой пояс сеанса можно прямо из конфигуратора или через встроенный язык: функция «ЧасовойПоясСеанса» покажет, какой пояс применяется к текущему пользователю. Дополнительно сравните результаты функций «ТекущаяДата» и «ТекущаяДатаСеанса» — расхождение между ними укажет на смещение между сервером и сеансом.

1. 1
   Сверьте системное время и часовой пояс на сервере 1С и сервере СУБД
2. 2
   Проверьте часовой пояс клиентского компьютера, где замечен сдвиг
3. 3
   Откройте свойства информационной базы и посмотрите заданный часовой пояс
4. 4
   Выполните во встроенном языке проверку ЧасовойПоясСеанса и сравните с ожидаемым
5. 5
   Сравните время создания тестового документа с реальным временем
6. 6
   Определите, сдвинуты только новые документы или старые тоже

Если база файловая, цепочка короче: значение имеют только настройки операционной системы компьютера, где лежит база, и пояс информационной базы. В клиент-серверном варианте добавляются настройки кластера 1С и SQL-сервера, и именно там чаще всего скрывается причина.

Проверка настроек сервера и СУБД

На сервере 1С:Предприятия проверьте системное время и часовой пояс операционной системы. В Windows это делается через параметры даты и времени, в Linux — через команду timedatectl. Убедитесь, что пояс соответствует фактическому местоположению сервера, а синхронизация времени по NTP работает корректно.

Сервер СУБД (MS SQL, PostgreSQL) имеет собственное представление о времени. Если сервер 1С и SQL-сервер расположены на разных машинах с разными часовыми поясами, сдвиг практически гарантирован. Оба сервера должны работать в одном поясе либо в согласованной схеме, где смещение учитывается осознанно.

Отдельный случай — виртуальные машины. Гипервизор может навязывать гостевой системе время хоста, и после перезагрузки сервера пояс или время «слетает». Если сдвиг появляется периодически, проверьте настройки синхронизации времени виртуальной машины с хостом.

Как исправить часовой пояс информационной базы

Самый управляемый способ устранить разночтения — явно задать часовой пояс в свойствах информационной базы. В консоли кластера серверов 1С откройте свойства базы и установите параметр часового пояса в нужное значение, например для конкретного региона. После этого все сеансы будут отображать время в едином поясе независимо от настроек клиентских машин.

В файловом варианте параметр задаётся через конфигуратор: «Администрирование» — «Параметры информационной базы», где устанавливается часовой пояс. После изменения пользователям потребуется перезайти в базу, чтобы новые настройки применились к их сеансам.

Сообщить(ЧасовойПоясСеанса());
Сообщить(ТекущаяДатаСеанса());

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

Что делать с документами, уже записанными со сдвигом

Настройка пояса исправляет отображение и запись новых данных, но не переписывает старые. Если документы физически созданы с неверным временем (например, в момент, когда сервер жил в другом поясе), их даты останутся смещёнными. Для УТ это критично: сдвинутое время влияет на последовательность проведения, остатки на конкретный момент и отчёты по периодам.

Корректировку накопленных данных выполняют обработкой, которая сдвигает время документов на нужную величину с последующим перепроведением. Такую операцию нельзя делать «на живую» в рабочей базе: сначала тест на копии, затем резервная копия рабочей базы, и только потом изменение с перепроведением документов в хронологическом порядке.

Как убедиться, что проблема решена

После изменения настроек создайте тестовый документ и сверьте его время с реальным. Затем проверьте отображение времени у нескольких пользователей с разных компьютеров: значения должны совпадать и соответствовать заданному поясу базы.

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

Частые вопросы