Системное время в 1С: настройка, синхронизация, NTP

У 1С нет собственных часов. Платформа берёт дату и время у операционной системы того компьютера, где выполняется код. Значит, чтобы «поставить часы» в программе, настраивают не 1С, а системное время Windows (или Linux) на нужной машине.

В файловой базе это часы вашего рабочего компьютера. В клиент-серверной — часы сервера, на котором крутятся рабочие процессы кластера. Если дата в документах, отчётах или журнале регистрации сбивается — проверяют именно их, а дальше настраивают автоматическую синхронизацию по NTP, чтобы время больше не «уплывало».

Ниже разберём, где конкретно 1С берёт время в каждом режиме, как его проверить изнутри программы и почему неверные часы ломают регламентные задания.

Откуда 1С берёт дату и время

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

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

Отсюда простое правило: неверное время в 1С почти всегда означает неверное время в операционной системе. Лечить надо ОС, а не программу.

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

• 🔋 села батарейка CMOS на материнской плате — после выключения питания часы сбрасываются;
• 🌍 неправильно выбран часовой пояс — время «правильное», но смещено на несколько часов;
• ☁️ виртуальная машина рассинхронизировалась с хостом — частая беда на VM под 1С;
• 🔌 отключена или не работает служба синхронизации времени (NTP);
• 🖥️ в сети несколько источников времени, и они противоречат друг другу.

Чтобы быстро понять, какой из случаев ваш, пройдитесь по симптомам:

Настройка времени на рабочей станции (файловая база)

В файловом варианте «сервером» фактически выступает ваш собственный компьютер: новые документы получают дату его операционной системы. Поэтому настраивают часы Windows на той машине, где открыта база.

Порядок для Windows 10/11 и Windows Server 2016 и новее:

1. Щёлкните правой кнопкой по часам в правом нижнем углу и выберите пункт настройки даты и времени (либо откройте Параметры → Время и язык → Дата и время).
2. Сначала проверьте часовой пояс — он должен соответствовать вашему региону. Ошибка в поясе смещает всё время, хотя минуты идут верно.
3. Включите автоматическую установку времени. Windows начнёт синхронизироваться с сервером времени Microsoft.
4. Если автоустановка недоступна (нет интернета, время не меняется) — выставьте дату и время вручную кнопкой изменения.

Форсировать синхронизацию из командной строки можно командой:

w32tm /resync /force

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

Время в клиент-серверном режиме

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

Что отсюда следует:

• настраивать и синхронизировать время нужно в первую очередь на сервере приложений 1С;
• если серверов в кластере несколько, держите их все на одном источнике времени;
• часы клиентских машин важны только для отображения локальных дат в интерфейсе, но не для значения ТекущаяДата() в серверном коде.

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

Для сервера 1С под Linux время настраивают средствами ОС. Часовой пояс и включение синхронизации задают через timedatectl:

timedatectl set-timezone Europe/Moscow
timedatectl set-ntp true
timedatectl

Если синхронизацией занимается служба chrony, её состояние и источники смотрят командами chronyc tracking и chronyc sources. Принцип тот же, что и в Windows: правильный часовой пояс плюс автоматическая синхронизация с надёжным сервером.

Синхронизация по сети: протокол NTP

NTP (Network Time Protocol) — это механизм, которым компьютеры подтягивают точное время из надёжного источника. Настроенный NTP снимает проблему «часы уплыли» раз и навсегда.

Если сервер в домене Active Directory. Рядовые машины автоматически синхронизируются с контроллером домена по иерархии: рабочие станции и серверы-члены домена берут время с ближайшего контроллера, контроллеры — с контроллера, который держит роль эмулятора PDC, а его уже настраивают на внешний источник точного времени. Отдельно на сервере 1С обычно ничего делать не нужно — достаточно, чтобы доменная иерархия времени работала. Если же эмулятор PDC синхронизируется «сам с собой», со временем расходится весь домен сразу.

Если сервер вне домена (рабочая группа). Настройте внешний источник вручную. На Windows это делает служба w32time:

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

Первая команда задаёт список серверов времени, затем служба перезапускается и выполняется разовая синхронизация.

Проверить, откуда и насколько успешно идёт синхронизация:

w32tm /query /status
w32tm /query /source

В выводе смотрят строку источника (Source) и смещение (Last Successful Sync Time, Phase Offset). Если источник — Free-running System Clock, значит синхронизация не настроена и часы идут «сами по себе».

Измерить фактическое расхождение с эталоном, не меняя часы, помогает команда:

w32tm /stripchart /computer:pool.ntp.org /samples:5 /dataonly

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

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

Чтобы убедиться, какое именно время «видит» программа, не нужно гадать по датам документов — его можно запросить напрямую.

Самый быстрый способ — выполнить в любой обработке или в консоли кода одну строку:

Сообщить(ТекущаяДата());

На сервере эта функция вернёт серверное время, на клиенте — время рабочей станции. Сравнив два значения, вы сразу поймёте, кто из них врёт.

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

Задаётся пояс базы программно, методом УстановитьЧасовойПоясИнформационнойБазы(); текущее значение возвращает ЧасовойПоясИнформационнойБазы(). Пояс конкретного сеанса показывает функция ЧасовойПоясСеанса(). Если эти значения не совпадают с ожидаемыми, причина расхождения дат может быть не в «сбитых часах», а именно в настройке часового пояса базы.

Короткий порядок проверки, когда дата «не та»:

Влияние времени на регламентные задания и отчёты

Неверные часы бьют не только по датам документов. Сильнее всего страдает автоматика.

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

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

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

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

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

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