В практике системного администрирования и разработки на платформе 1С:Предприятие иногда встречаются ошибки, которые кажутся абсурдными с точки зрения логики. Одной из таких проблем является ситуация, когда функция ТекущаяДата() внезапно начинает возвращать значение 01.01.1970 0:00:00. Это значение соответствует «началу эпохи» (Unix Epoch), и его появление обычно сигнализирует о глубоком техническом сбое во взаимодействии платформы с операционной системой.
В данной статье мы подробно разберем, почему возникает этот баг, как продиагностировать его причины и какие шаги необходимо предпринять для его устранения. Мы проанализируем сценарии совместной работы разных версий агентов 1С и выясним, почему стандартные функции получения года или месяца могут при этом продолжать работать корректно.
Рассмотрим типичную ситуацию: на сервере одновременно запущены два агента — версии 8.2 и 8.3. После обновления одного из них (например, до версии 8.3.12) в базах, работающих на старом агенте, начинаются сбои. При выполнении регламентных заданий или при работе пользователей в коде фиксируется дата 01.01.1970.
Проанализируем результаты выполнения следующего кода в момент возникновения ошибки:
ТекущаяДата = ТекущаяДата(); // Результат: 01.01.1970 0:15:00
Сообщить(Формат(ТекущаяДата, "ДФ=yyyy-MM-dd")); // Результат: 1970-01-01
Сообщить(Строка(Год(ТекущаяДата))); // Результат: 2 019
Сообщить(Строка(Месяц(ТекущаяДата))); // Результат: 1
Сообщить(Строка(День(ТекущаяДата))); // Результат: 21
Здесь мы видим удивительный парадокс: сама переменная ТекущаяДата хранит 1970 год, но функции Год(), Месяц() и День(), примененные к этой же переменной, возвращают правильные значения текущего календаря (например, 2019 год). Это происходит из-за того, что объект Дата в 1С имеет сложную внутреннюю структуру. В то время как основное значение может быть инициализировано «нулем» из-за сбоя системного вызова, кэшированные компоненты даты внутри рабочего процесса rphost могут сохранять актуальные данные. Это подтверждает, что проблема кроется не в системном времени сервера, а в механизме получения этого времени платформой 1С.
Первым делом нам необходимо убедиться, что системное время на сервере действительно стабильно. Выясним причину, не меняется ли время в самой операционной системе под воздействием внешних служб или сбоев батарейки CMOS (хотя для виртуальных серверов это редкость).
Для этого создадим простейший исполняемый файл (батник) для мониторинга времени вне контекста 1С и запустим его в планировщике задач или вручную:
@echo off
:loop
echo %DATE% %TIME% >> D:\Logs\ServerDateLog.txt
timeout /t 60
goto loop
Если в логах операционной системы время всегда отображается корректно, значит, проблема локализована внутри процессов rphost или ragent. Также рекомендуется временно отключить автоматическую синхронизацию времени с внешними NTP-серверами, чтобы исключить скачки времени в моменты синхронизации.
Рассмотрим одну из наиболее вероятных причин «залипания» даты в пользовательских сессиях. В платформе 1С существует параметр РабочаяДата. Иногда из-за ошибок в кэше или некорректного завершения сеанса это значение может установиться в «пустую» дату или 1970 год.
Попробуем выполнить следующую процедуру:
Поскольку проблема часто связана с тем, что рабочий процесс rphost «теряет» связь с системным таймером, нам необходимо выполнить полную очистку временных данных сервера приложений.
Разберем по шагам процесс очистки для сервера Windows:
1C:Enterprise 8.2 Server Agent.C:\Program Files\1cv82\srvinfo).snccntx* и временные файлы внутри папок конкретных информационных баз (каталоги с GUID). Внимание: не удаляйте файлы конфигурации кластера 1CV8Reg.lst, если у вас нет резервной копии списка баз.AppData\Local\Temp).Если ошибка возникает при достижении 100% нагрузки на процессор, проанализируем настройки рабочих процессов в консоли кластера. Рекомендуется установить лимит памяти на один рабочий процесс и настроить их периодический перезапуск (например, раз в 24 часа), чтобы предотвратить утечку дескрипторов (handles), которые могут блокировать системные вызовы времени.
Одной из самых глубоких причин является конфликт библиотек среды выполнения (Runtime). Версия 8.3.12 и выше использует обновленные версии библиотек Visual C++, которые могут конфликтовать со старыми вызовами агента 8.2 на одном ядре ОС. Платформа 8.2 ожидает определенного поведения от системных функций, которое перехватывается или модифицируется компонентами новой платформы.
Рассмотрим варианты решения этого конфликта:
System32 и реестр остаются общими.HKEY_CURRENT_USER.Если все вышеперечисленные методы не приносят стабильного результата, проанализируем наиболее радикальный, но надежный способ. Платформа 8.3 гораздо лучше адаптирована к современным операционным системам и корректно обрабатывает системные прерывания.
Посмотрим на алгоритм миграции:
Режим совместимости — Версия 8.2.13 или аналогичную вашей текущей версии.Появление даты 01.01.1970 в 1С — это сложный симптом, указывающий на сбой инициализации объекта Дата. Выясним причину: чаще всего это происходит из-за исчерпания ресурсов рабочего процесса или конфликта двух разных версий платформ на одном физическом сервере.
Для оперативного решения используйте очистку кэша и перезапуск рабочих процессов. Для стратегического решения проблемы мы рекомендуем отказаться от использования устаревшего агента 8.2 в пользу 8.3 с включенным режимом совместимости. Это обеспечит стабильность системных вызовов и корректную работу регламентных заданий без неожиданных «прыжков в прошлое».