Господа (и дамы),
рискую идти по лёгкому пути, но список предположений исчерпан, а проблема висит.

Содержание.
База УТ 10.3 досталась в наследство и вместе с ней "шкафные скелеты" предыдущих поколений (пока не пойму кого: программистов, либо сисадминов).
Имеет место регламентное задание, которое каждый божий рабочий день рассылает менеджерам письма с дебиторкой. При формировании заголовка и тела письма используются даты (документов, текущая), а так же указания на документы взаиморасчётов (ссылки).
Допустим, мы запускаем регламентное задание. Какое-то время (несколько дней, может даже недель) всё идёт нормально: пользователи получают письма, информация соответствует действительности, жизнь прекрасна.
Далее, наступает момент X. И...пользователи продолжают получать письма, но, все даты (собственно тип данных "Дата", либо реквизит документа типа "Дата", либо дата входящая в представление ссылки документа) преобразуются к единому знаменателю по части даты(не времени).

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

Заголовок письма "Дебиторская задолженность на 27.05.2016 17:01:06"
В теле письма
Реализация товаров и услуг АА000000620 от 27.05.2016 17:59:59
Реализация товаров и услуг АА000000640 от 27.05.2016 17:59:59
Итэдэ итэпэ.

Проблему не решает:
1) Перезапуск регламентного задания. Использование другого регламентного задания
2) Использование в коде даты сервера, представления ссылки на документ в виде строки.
3) Изменение месторасположения БД и сервера 1с.

Проблему решает
1) Перезапуск службы сервера 1с. Но это не решение.

Обработка исполняющая тот же функционал (отправку дебиторки на e-mail) отрабатывает даты корректно.(в нормальные и "эти" дни)

Собственно вопрос. Откуда ноги растут у этой проблемы?

"Лучше спросить и побыть дураком пять минут, чем промолчать и остаться им на всю жизнь." (народная китайская мудрость)

Ап.

Мне понравилась ваша китайская мудрость.
А в коде как задается заголовок письма?

(1) Что "ап"? Надо изучать алгоритмы. Возможно, где-то в алгоритме, случайно и не преднамеренно, значение переменной перезаполняется другой датой.

(2)         ПочтовоеСообщение=Новый ИнтернетПочтовоеСообщение; // собственно сообщение
        ПочтовоеСообщение.Тема = "Дебиторская задолженность на "+ТекущаяДата();

(3) "Ап", для поднятия темы.
"Папрашу" не давить интеллектом. Ибо алгоритм (процедура) изучен вдоль и поперёк и...
Для затравки заголовок в (4) , в котором чудесным образом преобразуется текущая дата в дату "с потолка". Используется функция ТекущаяДата() сразу с выводом в заголовок письма.
Если разбирать текст процедуры, то можно выделить следующие блоки
1) Получение и настройка учётной записи электронной почты.
2) Получение данных по дебиторской задолженности в разрезе менеджеров запросом.
3) Цикл в котором перебирается группировка менеджеров и далее, относительно неё строится текст письма. При получении ссылки на документ используется код формирующий строку представления
    ДокументРасчетов.Метаданные().Синоним + " "  + Строка(ДокументРасчетов.Номер) + " от " + Строка(ДокументРасчетов.Дата); // где док. расчётов - ссылка на документ.

Собсна всё.

Даже вот так извернём вопрос.
Абстрагируемся от "документРасчетов.Дата"

Каким образом функция "ТекущаяДата()" может преспокойно вернуть совсем не текущую дату? Причём в регламентном задании, причём не с момента первого запуска этого регламентного задания (а с любого другого раза).

(5) и да. П 3. конечно венчает отправка письма. Типа
Почта = Новый ИнтернетПочта;
Попытка
    Почта.Подключиться(Профиль);        
        Почта.Послать(ПочтовоеСообщение);
Исключение
    //Сообщить(ОписаниеОшибки());
    //Возврат
КонецПопытки;

судя по (0) разница 45 дней, скорее всего пересчет идет в процедуре получения отчета по ДЗ...смотреть туда

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

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

(10) тут не в значениях переменных дело - в момент существования проблемы лазил в отладчике и видел, что в переменных то, что должно быть, а при визуализации значения даты (в том числе при преобразовании даты в строку через Формат) - любое значение даты преобразуется к некоторому фиксированному, как в (0).

(11) В подобных случаях можно присвоить переменной,например, ДатаНачалаРассылки=ТекущаяДата(), чтобы уже не возвращаться к получению. Можно и формат применить при необходимости отрезания времени. Искать время у документов нет смысла. Оно зафиксировано в дате документа.
..возможно, я не всё понял из сабжа.

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

+(13) И это было везде - в отчетах, в дин. списках, в формах документов (открываешь любой существующий док - а у них всех одна и та же дата в форме, в отладчике на неё же смотришь - всё норм).

(11) на сервере лазил? или толстым клиентом?
возможно рассинхрон времени на сервере и клиенте...

(15) И на серваке, и с клиентских машин - правда, не со всех, заходил в отладчик, спецэффекты были одинаковы. Работаем в тонком, конфа на УФ

Всё чудесатее и чудесатее...

Две различные строки алгоритма <<"Дебиторская задолженность на "+ТекущаяДата()>> и <<" от " + Строка(ДокументРасчетов.Дата)>> не могут "ошибаться" одинаково.

"Нет, сынок, - это фантастика"(реклама сыра "Хохланд")

(17) Что, тоже эту блоху поймал? :)

(8) Получение дебиторки идёт "тут же" - запросом.

(18) Нет, высказал своё имхо. Если в байду насчет неверного неявного преобразования текущей даты с трудом, но могу поверить, то в подмену "на лету" даты документа - фантазии не хватает.

Я скорее в злобные вирусы, которые из вредности меняют даты в письмах, поверю.

(19)чудес не бывает

Кстати, бред белой горячки, но может быть автору стоит изменить даты на формат типа "27 мая 2016г."? :)

Может в базу лазят разными серверами приложений?

Или где-то периодически работает отладочное регламентное задание, копия рабочей базы (например копия от 27.05.2016)? Например, в файловой копии рабочей базы. Если регламенты не были отключены, то вход пользователя в базу может породить их запуск.

Или планировщик Винды

(10) Что это даст? Вот у меня процедура, выполняемая в регл. задании. Одна. В рамках этой процедуры при формирования заголовка письма используется ТекущаяДата(), которая спустя определённое время работы регл. задания искажается.
(21) Этот вариант я держу в уме. Но как проверить? Антивирь молчит.
(22) Это да.
(23) Вот это проверю.
(24) Как это можно проверить?
(25) Есть единственная тестовая база. Регламенты заблочены. Это не объясняет спонтанного появления проблемы.

(26) Уже осуществлялся перенос на другой сервер. Проблема сохранилась на новой винде. Скорее нет.

(27) Проверяется путем переноса инфобазы в рамках СУБД (новое имя / новый сервер БД). Тогда тот, кто лазит в эту инфобазу из другого кластера 1С, получит отлуп

(29) Проверю на выходных. Как раз сервер подготовил.

(30) Базу перенёс на новый сервер. Имя изменил. Пока полёт нормальный.

Ещё неделя прошла. Полёт всё ещё нормальный. Всем спасибо.