"Ошибка инициализации модуля: ВнешняяОбработка.ВосстановлениеНомерации.МодульОбъекта
по причине:
{ВнешняяОбработка.ВосстановлениеНомерации.МодульОбъекта(22)}: Ошибка при вызове метода контекста (НайтиПоНомеру)

по причине:
Ошибка в значении типа 'Дата'
Дата '31.12.0001 23:59:59' не может быть записана в базу данных на MS SQL Server с нулевым смещением дат"

Что такое смещение дат и зачем оно вообще нужно?

https://yandex.ru/search/?text=1С%20предприятие%20Что%20такое%20смещение%20дат%20и%20зачем%20оно%20вообще%20нужно%3F&lr=213&redircnt=1540916155.1

(0) А зачем такую дату записывать?

смещение дат сделано ради экономии места...

В диалоге "Добавление информационной базы/группы" при создании информационной базы на СУБД Microsoft SQL Server доступна установка параметра "Смещение дат". Раздел содержит дополнительную информацию о влиянии значения этого параметра на работу информационной базы.

Причина введения параметра
Необходимость установки данного параметра обусловлена отличием диапазонов значений дат, представимых объектом типа Дата в "1С:Предприятии 8" и представимых в полях типа DATETIME таблиц Microsoft SQL Server.

В "1С:Предприятии 8" даты могут принимать значения с 00:00:00 1 января 1 года по 23:59:59 31 декабря 9999 года, причем, записаны в базу данных могут быть даты с 00:00:00 1 января 1 года по 23:59:59 31 декабря 3999 года. Важно, что:

дата 00:00:00 1 января 1 года считается нулевой датой и значением по умолчанию для данных типа Дата;

даты с 00:00:00 1 января 1 года по 23:59:59 1 января 1 года считаются временем без даты.

В полях типа DATETIME таблиц Microsoft SQL Server могут быть представлены даты с 00:00:00 1 января 1753 года по 23:59:59 31 декабря 9999 года.

Таким образом, даты из с 00:00:00 1 января 1 года по 23:59:59 31 декабря 1752 года из "1С:Предприятия" невозможно записать без искажения в базу данных на Microsoft SQL Server.

Описание параметра
Для обхода этой особенности введен параметр информационной базы "Смещение дат".

Данный параметр определяет число лет, которое будет прибавляться к датам при их сохранении в базе данных Microsoft SQL Server и вычитаться при их извлечении. Он может принимать значения 0 или 2000.

Если установить смещение дат 0, то:

при записи дат в диапазоне с 00:00:00 1 января 1 года по 23:59:59 1 января 1 года даты будут переводиться в диапазон с 00:00:00 1 января 1753 года по 23:59:59 1 января 1753 года, а при чтении - обратно;
даты 1С:Предприятия с 00:00:00 2 января 1753 года по 23:59:59 31 декабря 3999 года будут записываться в базу данных без изменений;
попытка записи в базу данных дат с 00:00:00 2 января 1 года по 23:59:59 1 января 1753 года будет приводить к ошибке.
Если смещение дат установлено в 2000, то при записи в базу данных к дате будет прибавлено 2000 лет, а при чтении из базы данных - вычтено 2000 лет. Это позволит записывать в базу данных любые даты 1С:Предприятия. Однако, при этом незначительно снизится скорость работы с базой данных, и при просмотре базы данных средствами, отличными от 1С:Предприятия, все даты окажутся измененными.

Таким образом, если при работе с информационной базой может возникнуть необходимость хранения дат, предшествующих 1 января 1753 года, то в качестве значения параметра следует выбрать 2000. Если же такие даты встречаться не будут, то в качестве смещения дат можно выбрать 0.

Важно, что нулевое значение смещения дат может привести к нежелательным ошибкам. Эти ошибки возникают, если конфигурация все-таки выполняет попытки записи дат, предшествующих 1 января 1753 года, которые не планировались. Поэтому для смещения дат при создании информационной базы "1С:Предприятие 8.2" в качестве значения по умолчанию предлагает использовать значение 2000.

(4) Большое спасибо! Более чем доступно!

(5) Ты не подумаЙ, это не я такой умный, я тупо из ИТС скопировал(

(4) Вот только давно уже в MS SQL есть тип DATETIME2, который в таком смещении не нуждается, но менять 1С ничего не торопится.
https://docs.microsoft.com/ru-ru/sql/t-sql/data-types/datetime2-transact-sql?view=sql-server-2017

Это карма у тебя такая за "номерацию"

(7) От 2000 отказались только в 8.3. Наверное от 2005 в 8.4 не откажутся, а значит и датавремя2 тоже использовать не будут...

(8) нумераторов не счесть

(10) Хз о чем ты

(7) реально видел базы 1с с типом полей  DATETIME2...

(11) ТС решил выделиться из серой толпы

(9) А что мешало хранить датавремя в строке? В семерке так и было.

(13) А, ясно. Не, Я про карму не из-за гордыни автора, а из-за его грамотности имел в виду)

(14) В строке вообще все можно хранить. Видимо, МС не пошли таким путем, потому что не строки кое-когда обрабатывать быстрее, чем строки?

(9) Что мешает при создании базы в зависимости от версии СУБД использовать подходящий тип? Ведь невозможно понижать версию СКЛ, иначе как через выгрузку-загрузку.

(17) При следовании такому подходу на каждый чих будет по флажку. Диалог создания инфобазы будет перегружен.

(18) Так флажки-то и не нужны. Если версия выше 2005, то используй новый тип с 0 смещением, если нет, то старый, по умолчанию со смещением 2000.

(19) Либо им неохота запариваться над обратной совместимостью или конвертацией инфобазы (что делать с базами в которых уже используется "старый" тип и/или используется смещение), либо очкуют, что после такого поведения полезут ошибки в коде (где идет попытка записи в БД дат ранее 1753 года)

А зачем 1Сники вообще дают такую возможность выбирать - делать смещение или нет? Почему это жестко в платформе не прописано?

(21) Ну вот переложили ответственность на того, кто регистрирует базу в кластере: или чуть страдаешь от замедления, или от риска ошибок записи в БД. В первом случае непонятно, насколько это замедление.

(22) Кому может потребоваться записывать в базу 1С даты ранее 1900 года? Все случаи ошибок в базах с нулевым смещение дат были по одной причине: человек ошибся. И вместо 2018 года вбил, например, 0201 год.

(23) Видимо, ты не сталкивался с логическими ошибками в прикладном коде, в результате которых легко могут предприниматься какие-нибудь попытки записи "пустых" дат 01.01.0001 (где только время) в реквизит БД, который имеет тип "дата-время". Вот ошибку и получаем-с.

(24) Неа, см. (4). Ошибка будет при попытке записать дату начиная с 02.01.0001. И да, эти логические ошибки доставят гораздо меньше проблем, если у пользователя что-то не получится сделать, чем если ты будет искать почему программа работает неправильно, и после нескольких часов трассировки выйдешь на неправильную дату.

(25) А, ты прав, точняк: даты за 1 января 0001 года переводятся в даты за 1 января 1753 года. Ну все равно в 1С смещение 0 очкуют принудатильно использовать почему-то

*принудительно

(26) В свете этого не совсем понятно, почему при наличии смещения должны быть тормоза. Если есть смещение - мы просто отнимаем 2000 лет, если смещение нулевое, мы сначала проверяем дату на 1 января 1753 года, и только потом или вычитаем, или ничего не делаем. Ветвление гораздо неприятнее для более-менее новых процессоров, т.к. при неправильном предсказании это приводит к перезапуску конвейера, что в разы тормознее операции вычитания, которая, скорее всего, вообще будет бесплатной, т.к. загрузить исполнительные устройства на 100% очень сложно.