Как проверить время на сервере 1С

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

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

Откуда 1С берёт время: что именно нужно проверять

В клиент-серверной архитектуре участвуют минимум три источника времени: клиентский компьютер, сервер 1С:Предприятия (агент ragent и рабочие процессы rphost) и сервер СУБД (MS SQL, PostgreSQL, Oracle, IBM Db2). Каждый из них живёт на своей машине со своими часами, и рассинхронизация возможна на любом узле.

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

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

Проверка времени через ТекущаяДатаСеанса() в консоли кода

Самый прямой способ — выполнить код на встроенном языке и посмотреть, что вернёт функция. Если у вас есть доступ к конфигуратору или к внешней обработке «Консоль кода» (типовая обработка из состава инструментов разработчика или аналогичная), откройте её и выполните простой фрагмент:

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

Первая строка покажет дату и время сеанса, вторая — применённый часовой пояс, третья — универсальное время (UTC). Сравнение этих трёх значений сразу показывает, корректно ли настроен пояс: разница между временем сеанса и универсальным временем должна равняться смещению вашего пояса.

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

Сообщить("Сеанс: " + ТекущаяДатаСеанса());
Сообщить("Пояс: " + ЧасовойПоясСеанса());
Сообщить("UTC: " + ТекущаяУниверсальнаяДата());

Проверка времени через журнал регистрации

Журнал регистрации — удобный косвенный источник: он фиксирует события с отметками времени сервера. Откройте в конфигураторе «Администрирование → Журнал регистрации» или соответствующую команду в режиме предприятия и посмотрите время самого свежего события. Если оно заметно отличается от реального времени — часы сервера сбиты.

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

Ограничение метода: журнал может отображать время в часовом поясе просмотра, а не сервера, в зависимости от настроек отображения. Поэтому для точной диагностики сопоставляйте показания с результатом ТекущаяДатаСеанса() и с системным временем самой машины.

Проверка системного времени на сервере ОС

Чтобы понять, откуда растёт проблема, проверьте часы самой операционной системы сервера. На Windows-сервере подключитесь по RDP и выполните в командной строке time /t и date /t, а также w32tm /query /status — последняя команда покажет источник синхронизации времени и состояние службы W32Time.

На Linux-сервере используйте date для текущего времени и timedatectl status для проверки синхронизации по NTP: в выводе должно быть «System clock synchronized: yes» и указан корректный часовой пояс. Если синхронизация отключена, часы сервера со временем неизбежно «уплывут».

1. 1
   Выполните ТекущаяДатаСеанса() в консоли кода и запишите результат
2. 2
   Проверьте ЧасовойПоясСеанса() и ТекущаяУниверсальнаяДата()
3. 3
   Сверьте время ОС сервера 1С: date/timedatectl (Linux) или time и w32tm (Windows)
4. 4
   Проверьте время на сервере СУБД: SELECT GETDATE() (MS SQL) или SELECT now() (PostgreSQL)
5. 5
   Сравните все значения между собой и с эталонным временем
6. 6
   При расхождении настройте NTP-синхронизацию на отклонившемся узле

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

Если сервер 1С и сервер СУБД — разные машины, часы нужно проверить на обеих. Для MS SQL Server подключитесь через Management Studio и выполните SELECT GETDATE(); — запрос вернёт текущее время сервера баз данных. Для PostgreSQL используйте SELECT now();, для Oracle — SELECT SYSDATE FROM DUAL;.

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

Типичные причины расхождения времени и их устранение

Наиболее частая причина — не настроенная или неработающая синхронизация NTP. Проверьте, что сервер получает время от надёжного источника: в доменной сети Windows это обычно контроллер домена с ролью эмулятора PDC, на Linux — служба chrony или systemd-timesyncd с указанными NTP-серверами.

Вторая причина — виртуализация. Виртуальные машины могут синхронизировать время с гипервизором, и если хост сам живёт с неверными часами, все гостевые системы унаследуют ошибку. Определитесь с единой схемой: либо время берётся с хоста (тогда NTP настраивается на хосте), либо гостевая ОС синхронизируется самостоятельно, а интеграция времени с гипервизором отключена. Одновременная двойная синхронизация даёт «дрожащие» часы.

Третья группа причин — неверный часовой пояс или устаревшие данные о переходах на летнее/зимнее время. Симптом: время отстаёт или спешит ровно на целое число часов. Лечится установкой правильного пояса на уровне ОС и обновлением пакета tzdata (Linux) или обновлений Windows.

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

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

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

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