Почему время в документах 1С расходится с часами на стене и как это исправить

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

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

Часы операционной системы — главный источник времени для 1С

Любая функция даты в 1С в итоге обращается к системным часам. Вопрос только в том, к часам какого компьютера.

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

💡 В разработке правило такое. Дата для записи в документ или регистр — ТекущаяДатаСеанса(). Метка времени для журналов обмена и интеграций — ТекущаяУниверсальнаяДата(), чтобы не путаться в поясах. ТекущаяДата() на клиенте для учёта не используйте.

Как быстро сравнить время клиента и сервера

Разработчику или администратору с доступом к конфигурации хватит небольшой обработки. На форме — команда, которая выводит время клиента и вызывает серверную функцию:

&НаКлиенте
Процедура СравнитьВремя(Команда)
	ВремяКлиента = ТекущаяДата();
	ВремяСервера = ВремяНаСервере();
	Разница = ВремяКлиента - ВремяСервера;
	Сообщить(СтрШаблон("Клиент: %1, сервер: %2, разница: %3 сек.",
		ВремяКлиента, ВремяСервера, Формат(Разница, "ЧН=0; ЧГ=0")));
КонецПроцедуры

&НаСервереБезКонтекста
Функция ВремяНаСервере()
	Возврат ТекущаяДата();
КонецФункции

Разница в пару секунд — норма, это задержка вызова. Минуты и больше — часы одного из компьютеров не синхронизированы. Ровно 3600 секунд и кратные им — компьютеры живут в разных часовых поясах.

Где «сервер», если база файловая

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

• 🖥️ Пять бухгалтеров в одной файловой базе — пять источников времени.
• 🌐 Если файловая база опубликована на веб-сервере, серверный код работает на веб-сервере, и время берётся с него.
• 📁 Компьютер, где лежит файл 1Cv8.1CD, на время не влияет: это просто хранилище файла.

NTP и синхронизация времени на серверах 1С

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

Windows: служба времени w32time

Проверить состояние и источник:

w32tm /query /status
w32tm /query /source

Если в источнике стоит Local CMOS Clock или Free-running System Clock, сервер ни с кем не синхронизируется. Для отдельного сервера вне домена можно задать внешние серверы точного времени:

w32tm /config /manualpeerlist:"ntp1.vniiftri.ru ntp2.vniiftri.ru" /syncfromflags:manual /update
net stop w32time
net start w32time
w32tm /resync

Перезапуск службы времени сеансы 1С не обрывает — это безопасная операция в рабочее время.

В домене Active Directory так делать не нужно. Рядовые серверы и рабочие станции берут время у контроллеров домена (/syncfromflags:domhier), а внешний NTP настраивают только на контроллере с ролью эмулятора PDC.

Linux: chrony или systemd-timesyncd

timedatectl
chronyc tracking
chronyc sources

В выводе timedatectl смотрите строку System clock synchronized: yes. Если там no, включите синхронизацию: timedatectl set-ntp true — или настройте серверы в /etc/chrony/chrony.conf (путь зависит от дистрибутива).

Виртуальные машины

Гипервизоры (Hyper-V, VMware) умеют сами подводить часы гостевой системы. В домене это конфликтует с синхронизацией от контроллеров: два источника перетягивают часы друг у друга. Выберите один — обычно доменную иерархию — и отключите синхронизацию времени в службах интеграции гипервизора для этой ВМ.

Время в кластере серверов 1С

В клиент-серверном варианте серверный код выполняет рабочий процесс rphost. Если в кластере два рабочих сервера и больше, вызов конкретного пользователя может попасть на любой из них. Часы этих серверов должны совпадать, иначе:

• ⏱️ ТекущаяДатаСеанса() у одного и того же пользователя «прыгает» от вызова к вызову;
• 📜 журнал регистрации показывает события не в том порядке, в каком они произошли;
• 🔁 регламентные задания запускаются по часам сервера, где их выполнил рабочий процесс, — при расхождении задание стартует раньше или позже расписания;
• 🔐 при входе с аутентификацией операционной системы домен проверяет расхождение часов: по умолчанию Kerberos допускает не больше 5 минут, сверх этого вход не проходит.

Расписание регламентных заданий привязано к местному времени сервера, а не к часовому поясу базы. Если сервер стоит в Москве, а компания в Новосибирске, задание «в 02:00» сработает в 02:00 по Москве, то есть в 06:00 по Новосибирску. Учитывайте это, когда ставите ночные загрузки и обмены.

💡 Проверить, нет ли разницы, проще всего одной командой на каждом сервере кластера: w32tm /query /status на Windows или chronyc tracking на Linux. Смещение (offset) больше одной-двух секунд — повод разобраться с источником NTP.

Сервер СУБД: влияет ли его время на 1С

Распространённое заблуждение — что 1С берёт время у SQL-сервера. Нет. Дату документа, ТекущаяДатаСеанса() и время в журнале платформа получает на сервере 1С и передаёт в СУБД как обычное значение. Функции даты самой СУБД (GETDATE() в Microsoft SQL Server, now() в PostgreSQL) при записи данных 1С не используются.

Часы СУБД всё равно важны, но по другим причинам:

• 💾 задания резервного копирования и обслуживания (агент SQL Server, cron для PostgreSQL) идут по часам сервера СУБД;
• 🔐 подключение сервера 1С к SQL Server с проверкой подлинности Windows опирается на Kerberos, а там действует тот же лимит в 5 минут;
• 🧾 при разборе инцидентов вы сопоставляете журналы СУБД, журнал регистрации 1С и технологический журнал — с разными часами это мучение.

Поэтому сервер СУБД синхронизируют с тем же источником, что и серверы 1С.

📌 Часовой пояс в даты 1С не входит. В таблицах базы хранится «голое» значение даты и времени без пояса. Если перенести базу на сервер в другом поясе, уже записанные даты не сдвинутся. Сдвинется только то, что пишется после переноса.

Часовые пояса и переход времени в 1С

С поясами в 1С работают три уровня:

1. Пояс операционной системы сервера — от него зависит ТекущаяДата() на сервере.
2. Пояс информационной базы — задаётся для всей базы. Программно: УстановитьЧасовойПоясИнформационнойБазы() и ПолучитьЧасовойПоясИнформационнойБазы(). В типовых конфигурациях на БСП он вынесен в общие настройки раздела Администрирование.
3. Пояс сеанса — по умолчанию равен поясу базы, но код может сменить его для конкретного пользователя через УстановитьЧасовойПоясСеанса(). Прочитать текущий — ЧасовойПоясСеанса().

Пример. Сервер 1С в Москве (UTC+3), филиал в Екатеринбурге (UTC+5). В 10:00 по Москве ТекущаяДата() на сервере вернёт 10:00. Если пояс сеанса бухгалтера филиала — Екатеринбург, ТекущаяДатаСеанса() вернёт 12:00, и документ получит местное время филиала.

Летнее время и смена правил

В России с 26 октября 2014 года сезонного перевода часов нет. Но правила поясов меняются: регионы переходили из одного пояса в другой и позже. Платформа узнаёт о таких изменениях из правил часовых поясов ОС. Если на сервере не установлены обновления с новыми правилами, все функции даты сдвинутся на час для затронутого региона.

Чтобы этого не случилось:

• 🔄 ставьте обновления ОС на серверах 1С и СУБД, в том числе пакеты часовых поясов (tzdata в Linux);
• 🆕 держите платформу на актуальном релизе — исправления, связанные с поясами, выходят и в ней;
• 🌍 проверяйте пояс сервера командой tzutil /g в Windows или timedatectl в Linux.

Время в облаке: 1С:Fresh и арендованные серверы

В облачном сервисе вы не управляете часами серверов — за NTP и пояса отвечает провайдер. Пользователю остаётся проверить одну вещь: какой часовой пояс задан для его приложения (базы) в сервисе.

Как это устроено на практике:

• ☁️ серверы облака обычно стоят в одном поясе — чаще московском;
• 🏢 для приложения задают свой пояс, и даты документов пишутся по нему через ТекущаяДатаСеанса();
• 🕐 если в документах время сдвинуто на целое число часов, почти всегда виноват пояс приложения, а не часы сервера.

При аренде виртуального сервера (не 1С:Fresh, а обычная ВМ с вашей 1С) ситуация другая. ОС ваша — значит, NTP и пояс настраиваете вы, по разделам выше. Особенно проверьте пояс: образы ВМ часто разворачиваются в UTC, и тогда 1С без заданного пояса базы пишет время на 3 часа меньше московского.

Типичные сбои времени в 1С и что с ними делать

Сначала определите характер сдвига: на целое число часов или на произвольные минуты. Это сразу отделяет проблему поясов от проблемы часов.

Ещё две ошибки встречаются на практике:

• 🔐 Не работает интернет-поддержка, ЭДО или отправка отчётности. Защищённое соединение проверяет срок действия сертификатов. Если часы компьютера ушли на дни или годы (садится батарейка BIOS), сертификат кажется «ещё не действующим» или просроченным. Сначала часы, потом всё остальное.
• 🗓️ После «подкрутки» часов вручную в базе появились документы с датой из будущего. Найдите их отбором по дате в журнале документов и исправьте дату. Перепроводить документы в закрытом периоде без согласования с главным бухгалтером не стоит.

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