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

Выражение                                                                        Значение                Тип
ЗанятостьРабочихЦентров[325].Период                                             17.12.2018  8:00:32     Дата
ПараметрыПоиска.Период                                                          17.12.2018  8:00:32     Дата
День(ЗанятостьРабочихЦентров[325].Период) = День(ПараметрыПоиска.Период)        Истина                Булево
Месяц(ЗанятостьРабочихЦентров[325].Период) = Месяц(ПараметрыПоиска.Период)      Истина                Булево
Год(ЗанятостьРабочихЦентров[325].Период) = Год(ПараметрыПоиска.Период)          Истина                Булево
Минута(ЗанятостьРабочихЦентров[325].Период) = Минута(ПараметрыПоиска.Период)    Истина                Булево
Секунда(ЗанятостьРабочихЦентров[325].Период) = Секунда(ПараметрыПоиска.Период)  Истина                Булево
Час(ЗанятостьРабочихЦентров[325].Период) = Час(ПараметрыПоиска.Период)          Истина                Булево
ЗанятостьРабочихЦентров[325].Период = ПараметрыПоиска.Период                    Ложь                  Булево
ЗанятостьРабочихЦентров[325].Период - ПараметрыПоиска.Период                    0,88                  Число

ЗанятостьРабочихЦентров[325].Период - ПараметрыПоиска.Период

В табличке последняя строка: 0,88
Не понимаю, как так может быть...

было такое. точность в секундах 2 знака после запятой(приблизительно).
Волшебник сказал - это фича.

Уверен, что дата, а не граница?

0,88 секунды?

для точного позиционирования еще в 1с77 использовалась ПозицияДокумента а не дата, поскольку в последнюю секунду дня сваливали все подряд.

'0001-01-01' + цел('0001-01-01' - data)

может так...
а лучше точно вешать в граммах (с)

(3) А как же тогда мою дату ПараметрыПоиска.Период округлить? Чтобы НачалоМинуты было - это я знаю, а НачалоСекунды - без понятия :)
(4), (6) Это дата начала выполнения технологической операции, она живет в табличной части с типом Дата (состав даты: Дата и Время)

(8) ответ в вопросе содержится.
Даты не равны.
разность дат = 0,88
ЗанятостьРабочихЦентров[325].Период - ПараметрыПоиска.Период                    0,88                  Число
это в секундах.
поэтому отображается одинаково.
что еще нужно?
если надо чтобы были равны до секунд - отбрасывайте все, что после целых секунд.

(0) В 1С даты представлены с точностью до секунды, а в базе MS SQL, например, с точностью до 100 наносекунд.

Пробуй при заполнении этого поля использовать преобразование дату в строку, а потом снова в дату и записывать в это поле


СтрокаДата = Формат(ТвояДата, "ггггММддЧЧммсс");
МоеПоле = Дата(СтрокаДата);

(8)Ну пересобери тем же год, месяц, день. Если для сравнения, то можно не на равенство проверять, а на то, что разница меньше 1.

(11)(12) +
""+data1 = ""+data2

ужас нах...

(0) Что за конфигурация? Какая платформа 1С и СУБД?

Офигеть, запустил табло на ОФ
('20180101'+0.111111111)-'20180101'
возращает 0,1111. Секунды с точностью 4 знака. Это баг или фича? База файловая

(9) Для меня это новость, что даты в 1с могут иметь точность сотые доли секунды. Я недавно программирую.
Шутка в том, что это одна и та же дата, только моя получена запросом, а вторая из ТЧ.
Получается, запрос "все портит". Находит ту же самую дату с более высокой точностью. Моя база файловая (она тестовая).
(14) 1С:Предприятие 8.3 (8.3.10.2561), конфа Управление производственным предприятием, редакция 1.3 (1.3.105.1)

(15) не баг и не фича. оно так работает, и это "правель"

(17) Как жить дальше... пойду домой.

не хватает функции НачалоСекунды()

но, её написать - дело шести секунд

(17) как это не баг. В документации такого нет. А теперь получается, что в поле с типом дата можно хранить наносекунды, просто их пользователь не увидит. Жуть какая.

(16)Ну, то, что секунда внутри еще делится на интервалы очевидно же. Хотя бы из существования границ :) С таким наглядным эффектом первый раз тоже сталкиваюсь, но что ж так шокироваться?

(19) +
Функция НачалоСекунды(Дат)
    Возврат НачалоМинуты(Дат) + Секунда(Дат);
КонецФункции

(17) Не баг, в СП написано
"Дата (Date)
Описание:
Значения данного типа содержат дату григорианского календаря (с 01 января 0001 года) и время с точностью до 0,1 миллисекунды."

Но блин ни одного метода чтобы с этими миллисекундами работать. Для меня это новость года, на 17-м году работы с 1С узнать такую фичу.
Почему мы ни разу не столкнулись с такой хренью как (0)? Сериализация кстати миллисекунды игнорит, это по сути баг.

(0) сравнивай так:
ЗанятостьРабочихЦентров[325].Период - ПараметрыПоиска.Период < 1

(25) -100000 тоже < 1

В 8.2.19 еще было "до секунды".
Но фокус из (15) работает.
Дата (Date)
Описание:
Значения данного типа содержит дату григорианского календаря (с 01 января 0001 года) и время с точностью до секунды.

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

(27)На 8.2.18 тоже воспроизводится)))

(13) ИМХО, лучше, чтобы в это поле в документе уже записывалась "округленная" дата, т.к. он выборку делает запросом и т.д., чтобы потом не заморачиваться. Но как сравнение - да, самый простой способ в (13)

(25) Если бы это было сравнение, то без проблем, а мне нужно использовать метод ЗанятостьРабочихЦентров.НайтиСтроки(ПараметрыПоиска) и среди параметров поиска РабочийЦентр (на котором выполняется техоперация) и этот Период тупой. Я ж не знаю заранее разницу между датой из табличной части и датой, полученной запросом...

При сохранении в базу дата документа округляется до секунд
    Док = Документы.АвансовыйОтчет.СоздатьДокумент();
    ТД = ТекущаяДата();
    сообщить(ТД - Дата(""+ТД));//0
    
    Док.Дата = ТД + 0.5;
    сообщить(Док.Дата - Дата(""+ТД));//0.5
    
    Док.Записать();
    
    ДатаИзБазы = Док.Ссылка.Дата;
    
    сообщить(ДатаИзБазы - Дата(""+ДатаИзБазы));//0

(32) возможно влияет режим совместимости, запускалось на упп

(31) приводи все данные(и ТЗ, и ПараметровПоиска) к секундной точности и будет тебе щасте

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

(28) бывает таблицы нужно по датам соединять в запросах.

Заметил, что в регистре бухгалтерии добавили поле "длина уточнения периода". Может из-за этого теперь в дате миллисекунды завелись.

(34) Это не ТЗ, а ТЧ. И там период уже хранится "как есть" с милисекундной точностью. Мне нужно выбрать строки из ТЧ методом НайтиСтроки (один из параметров поиска мой период) и затем в найденных строках поменять кое-что.

(34) Ещё скажи, что все всегда так делают
(35) позиция и граница это другие типы

(37) А откуда данные попали в ТЧ?

(36)Запрос приводит даты к секунде, я проверила) И тоже не могу вспомнить соединения по дате. По периоду было, а чтоб прям по дате?

(39) План производства по сменам сформировался. Операции из техкарт попали в него в результате планирования.

(38) "я сто раз так делал" (с)
(37) без разницы. Если ты хочешь искать данные в этой таблице, значит формат параметров поиска должен совпадать с форматом данных.

(42) Ха-ха, ну по-любому :) Это ясное дело.

(41) и ты хочешь сказать, что операции планируются с точностью до миллисекунд? Или их все таки можно округлять перед записью?

(40) а, т.е. получается, что это проблемы только даты, которая вычислена в оперативной памяти компьютера (причем именно вычислена, т.к. пользователь в поле с датой миллисекунды выбрать не может). Тогда не понятно назначение такого функционала в платформе.

(45) я даже больше скажу: я не уверен, что эти доли секунд соответствуют действительности

Сообщить(ЗаписатьДатуJSON('20180101' + 0.111, ФорматДатыJSON.JavaScript, ВариантЗаписиДатыJSON.УниверсальнаяДата));

выдает:
new Date(1514754000111)

(46) вот так работаешь более 10 лет с восьмеркой и узнаешь новое про примитивный тип Дата.
Хочется все сертификаты разорвать.

(44) Да, это типовая конфа. Получается, с точностью до миллисекунд.

(49) на поддержке?

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

сделал аналогично (32) запись в реквизит документа и реквизит табличной части в пустой конфе (без режима совместимости): все даты округлились после записи в базу.
Как (0) удалось это обойти?

(50) так если запрос при получении данных округляет до секунд, то зачем при записи их округлять?

Да, тоже проверил на 8.3.13 - в справочнике при записи дата округлилась до секунды.

(51) может какая то загрузка данных была нештатная?

в (41) написано что план формировался автоматом. наверняка когда создавались документы бралось текущее время без всяких округлений и писалось с высокой точностью.

(54) сделал Док.ОбменДанными.Загрузка = Истина
, ничего не изменилось.
Или думаешь ТС в файловую базу что-то пишет минуя платформу?

(55) "бралось текущее время без всяких округлений" как это сделать? ТекущаяДата возвращает округленную

(55) "писалось с высокой точностью" - вопрос тот же, Как?

(55) Все планы производства так формируются, к сожалению, мне сложно найти место в конфе, где это описано, там вычисляется время исполнения технологической операции с конца, от даты окончания отнимается длительность операции и получается "Период" (то есть фактически дата начала исполнения).

(59) Расчет может объяснить откуда взялись такие даты, но как тебе их удалось записать в базу?
Или у тебя строки ТЧ незаписанного документа?

(60) ТЧ проведенного документа.

(61) ХЗ. Ни у кого здесь не получилось записать дату с миллисекундами в базу. А у тебя ещё и режим совместимости с 8.2.

(62) Конечно, Версия 8.2.13

(63) может дата всё-таки не берется из записанного документа, а считается как в (59). Тогда всё объяснимо.

(64) Моя доработка запускается, когда план уже полностью сформирован и проведен. Так что данные в ТЧ уже хранятся. Как - не могу ответить, с трудом читаю чужой программный код такой сложный, как в посменном планировании.

ВСЕМ СПАСИБО ЗА ПОМОЩЬ. Тип Дата для меня открылся с совершенно другой стороны :)

(62) Проверил на УПП в режиме совместимости 6.2.13. Чуда не произошло - при записи в базу миллисекунды отбрасываются.
(64) Предполагаю, что проблема автора кроется не в ТЧ документа, а в переменной "ПараметрыПоиска.Период".

Тьфу, не "6.2.13" разумеется, а "8.2.13". Проверял и в SQL, и в файловом режиме.

(66) тоже думаю, что ТС как-то считает одну из дат. Но он не колется, говорит "из записанного документа"

(68) Поскольку ЗанятостьРабочихЦентров[325].Период - ПараметрыПоиска.Период = 0,88, то миллисекунды есть в ТЧ в строке 325 в дате "Период".
Я очень хочу разобраться ради установления истины :)

похоже там табличная часть пересчитывается в какой то момент, вопрос в какой?

(70) Попробую объяснить суть работы. Это перепланирование, из ТЧ удаляются все техоперации старой детали (узла) и техоперации всех подчиненных деталей (узлов), из которых она состоит. Затем на их место планируется выпуск новой похожей детали, которую выбрал пользователь. У нас изготовление одной и той же детали возможно 5 способами (применяются разные технологии литья и разное оборудование, соответственно, разные спецификации и техкарты, а деталь на выходе та же). Только время ее изготовления будет другое.
И вот дата начала 1-2 из десятков новых операций при перепланировании иногда совпадает с датой начала какой-нибудь старой операции из плана (относящейся не к перепланируемой детали, а к какой-то другой, деталей в каждой готовой продукции около 1000, в каждой от 1 до 15 операций). Вот я и ищу эту старую строку в плане и от ее Периода хочу отнять секунду. Понятно, что совпадение дат начала операции на одном и том же рабочем центре - это ошибка планирования, поскольку оборудование уже занято и что-то другое одновременно на нем изготавливаться не может. Но я хочу пока просто обойти эту проблему, устранив совпадение дат, чтобы перепланирование заработало в общем, а потом уже решать мелкие проблемы. Потому что из тысяч правильных операций таких с совпавшими датами или пересекающимися периодами занятости рабочего центра всего 1-3.
Единственное, могу предположить, что при удалении старых строк из ТЧ по перепланируемой детали пересчитываются все оставшиеся строки ТЧ, но я после удаления делаю проведение документа, чтобы сведения о занятости рабочих центров попали в регистры, а сведения о занятости по удаляемой детали, наоборот, вычистились.

(71)
объект перечитать
?

(71) "после удаления делаю проведение документа" документ же после этого не перечитывается? Возможно ДокументОбъект продолжает содержать дробные даты, хотя в базу уже записаны округленные

(73) Нет, после этого не перечитывается.

(71) на самом деле чтобы избежать этого головняка просто округляй вычитаемую длительность до секунд

(75) Уже сделано и все получилось :)

(74) так попробуй перечитать

(77) очевидно всё вылечится. Записать дату с миллисекундами (пока?) нельзя.

(78) Потом, когда станет можно, возникнут те же проблемы с долями миллисекунд )))

(79) там уже доли, точность - 0.1 мс
Непонятно зачем сейчас такой функционал, если толком его нельзя использовать. Но уже можно (при должном старании) поймать/создать баг как в (0)

(80) MS SQL хранит даты с точностью до 100 наносекунд.

(81) 1С ограничилась 100 мкс, но пока не хранит ;)

(82) A PostgreSQL с точностью до 1 мкс.

(79) не возникнет...когда они будут писаться, данные будут такие же, как и в тз

(79) + тьфу...не понял тебя сразу...да, с долями милисекунд будут проблемы)

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

СП:
Дата (Date)
Описание:
Значения данного типа содержат дату григорианского календаря (с 01 января 0001 года) и время с точностью до 0,1 миллисекунды.

(47) выдает:
new Date(1514736000111)

(88) ТекущаяУниверсальнаяДатаВМиллисекундах()

(89) это число причём целое, а здесь про  (24) и (87)

(90) это, как я понял,  про возможное смещение относительно UTC.
А я написал про то, что во первых - это все же фича, раз оно реально может использоваться. Во вторых, возможно(сильно не факт) - эта фича появилась вместе с json.

(91) Пляшут от количества байт выделяемых для этого типа данных. Далее определяются с тем, какие границы дат нужны. В результате получается точность. В 1С могли бы определить точность в 1 мс. Но тогда границы дат были бы не 4000 лет, а 40000 лет. Просто подумали - ну зачем нам это, давайте лучше точности добавим.

(90) Это про то, что универсальная дата изначально имела миллисекунды и это даже не секрет Полишинеля, а (47)  - "Первооткрывателям Америки посвящается" :)

(25) А если в сравнение попадут, скажем, даты '20130724132506.9' и '20130724132507.1' (запись условная)? Разница в 0.2 секунды, но при отбрасывании десятых долей разница уже одна секунда.

(0) в запросе сделай НАЧАЛОПЕРИОДА(ТвоеВыражение,Секунда)

(11) извращение, сродни тем, которые применял ныне покойный Андрей Романович Чикатило.

(95)Запрос и так приводит время к секундам.

(97) есть куча других способов к секундам привести
Например:
Функция ДатаВремяДоСекунд(ДатаВремя)
   Возврат Дата(Год(ДатаВремя),Месяц(ДатаВремя),День(ДатаВремя),Час(ДатаВремя),Минута(ДатаВремя),Секунда(ДатаВремя));
КонецФункции

(98)Чем это лучше (11)?

(98) Можно проще. Подсказка: любая функция работы со значением типа "Дата" отрезает лишнее :) "НачалоМинуты(ДатаВремя) + Секунда(ДатаВремя)", "ДобавитьМесяц(ДатаВремя, 0)" и т.д.

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

(101)Ну, пока ни у кого в теме, кроме ТС(по его словам) не получилось.

(102) у него тоже не получилось

+(103) смотри (71) и (74)

(104)А, ну тогда вообще никаких проблем)