Вход | Регистрация

  1  2   
1С:Предприятие :: 1С:Предприятие 8 общая

Одинаковые даты не равны

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

Выражение                                                                        Значение                Тип
ЗанятостьРабочихЦентров[325].Период                                             17.12.2018  8:00:32     Дата
ПараметрыПоиска.Период                                                          17.12.2018  8:00:32     Дата
День(ЗанятостьРабочихЦентров[325].Период) = День(ПараметрыПоиска.Период)        Истина                Булево
Месяц(ЗанятостьРабочихЦентров[325].Период) = Месяц(ПараметрыПоиска.Период)      Истина                Булево
Год(ЗанятостьРабочихЦентров[325].Период) = Год(ПараметрыПоиска.Период)          Истина                Булево
Минута(ЗанятостьРабочихЦентров[325].Период) = Минута(ПараметрыПоиска.Период)    Истина                Булево
Секунда(ЗанятостьРабочихЦентров[325].Период) = Секунда(ПараметрыПоиска.Период)  Истина                Булево
Час(ЗанятостьРабочихЦентров[325].Период) = Час(ПараметрыПоиска.Период)          Истина                Булево
ЗанятостьРабочихЦентров[325].Период = ПараметрыПоиска.Период                    Ложь                  Булево
ЗанятостьРабочихЦентров[325].Период - ПараметрыПоиска.Период                    0,88                  Число
 
 
   НЕА123
 
1 - 15.11.18 - 10:36
ЗанятостьРабочихЦентров[325].Период - ПараметрыПоиска.Период
   qq001
 
2 - 15.11.18 - 10:38
В табличке последняя строка: 0,88 
Не понимаю, как так может быть...
   НЕА123
 
3 - 15.11.18 - 10:39
было такое. точность в секундах 2 знака после запятой(приблизительно).
Волшебник сказал - это фича.
   1Сергей
 
4 - 15.11.18 - 10:39
Уверен, что дата, а не граница?
   Bigbro
 
5 - 15.11.18 - 10:40
0,88 секунды?
   Bigbro
 
6 - 15.11.18 - 10:41
для точного позиционирования еще в 1с77 использовалась ПозицияДокумента а не дата, поскольку в последнюю секунду дня сваливали все подряд.
   НЕА123
 
7 - 15.11.18 - 10:44
'0001-01-01' + цел('0001-01-01' - data)

может так...
а лучше точно вешать в граммах (с)
   qq001
 
8 - 15.11.18 - 10:45
(3) А как же тогда мою дату ПараметрыПоиска.Период округлить? Чтобы НачалоМинуты было - это я знаю, а НачалоСекунды - без понятия :)
(4), (6) Это дата начала выполнения технологической операции, она живет в табличной части с типом Дата (состав даты: Дата и Время)
   Bigbro
 
9 - 15.11.18 - 10:48
(8) ответ в вопросе содержится.
Даты не равны.
разность дат = 0,88
ЗанятостьРабочихЦентров[325].Период - ПараметрыПоиска.Период                    0,88                  Число
это в секундах.
поэтому отображается одинаково.
что еще нужно?
если надо чтобы были равны до секунд - отбрасывайте все, что после целых секунд.
   exwill
 
10 - 15.11.18 - 10:50
(0) В 1С даты представлены с точностью до секунды, а в базе MS SQL, например, с точностью до 100 наносекунд.
 
 Рекламное место пустует
   Jackman
 
11 - 15.11.18 - 10:52
Пробуй при заполнении этого поля использовать преобразование дату в строку, а потом снова в дату и записывать в это поле

СтрокаДата = Формат(ТвояДата, "ггггММддЧЧммсс");
МоеПоле = Дата(СтрокаДата);
   catena
 
12 - 15.11.18 - 10:53
(8)Ну пересобери тем же год, месяц, день. Если для сравнения, то можно не на равенство проверять, а на то, что разница меньше 1.
   НЕА123
 
13 - 15.11.18 - 10:59
(11)(12) +
""+data1 = ""+data2

ужас нах...
   ptiz
 
14 - 15.11.18 - 10:59
(0) Что за конфигурация? Какая платформа 1С и СУБД?
   RomanYS
 
15 - 15.11.18 - 11:06
Офигеть, запустил табло на ОФ
('20180101'+0.111111111)-'20180101'
возращает 0,1111. Секунды с точностью 4 знака. Это баг или фича? База файловая
   qq001
 
16 - 15.11.18 - 11:11
(9) Для меня это новость, что даты в 1с могут иметь точность сотые доли секунды. Я недавно программирую.
Шутка в том, что это одна и та же дата, только моя получена запросом, а вторая из ТЧ.
Получается, запрос "все портит". Находит ту же самую дату с более высокой точностью. Моя база файловая (она тестовая).
(14) 1С:Предприятие 8.3 (8.3.10.2561), конфа Управление производственным предприятием, редакция 1.3 (1.3.105.1)
   1Сергей
 
17 - 15.11.18 - 11:12
(15) не баг и не фича. оно так работает, и это "правель"
   qq001
 
18 - 15.11.18 - 11:13
(17) Как жить дальше... пойду домой.
   1Сергей
 
19 - 15.11.18 - 11:15
не хватает функции НачалоСекунды()
   1Сергей
 
20 - 15.11.18 - 11:16
но, её написать - дело шести секунд
   Eiffil123
 
21 - 15.11.18 - 11:17
(17) как это не баг. В документации такого нет. А теперь получается, что в поле с типом дата можно хранить наносекунды, просто их пользователь не увидит. Жуть какая.
   catena
 
22 - 15.11.18 - 11:17
(16)Ну, то, что секунда внутри еще делится на интервалы очевидно же. Хотя бы из существования границ :) С таким наглядным эффектом первый раз тоже сталкиваюсь, но что ж так шокироваться?
   1Сергей
 
23 - 15.11.18 - 11:18
(19) +
Функция НачалоСекунды(Дат)
    Возврат НачалоМинуты(Дат) + Секунда(Дат);
КонецФункции
   RomanYS
 
24 - 15.11.18 - 11:19
(17) Не баг, в СП написано
"Дата (Date)
Описание:
Значения данного типа содержат дату григорианского календаря (с 01 января 0001 года) и время с точностью до 0,1 миллисекунды."

Но блин ни одного метода чтобы с этими миллисекундами работать. Для меня это новость года, на 17-м году работы с 1С узнать такую фичу.
Почему мы ни разу не столкнулись с такой хренью как (0)? Сериализация кстати миллисекунды игнорит, это по сути баг.
   olegves
 
25 - 15.11.18 - 11:19
(0) сравнивай так:
ЗанятостьРабочихЦентров[325].Период - ПараметрыПоиска.Период < 1
   RomanYS
 
26 - 15.11.18 - 11:20
(25) -100000 тоже < 1
   ptiz
 
27 - 15.11.18 - 11:21
В 8.2.19 еще было "до секунды".
Но фокус из (15) работает.
Дата (Date)
Описание:
Значения данного типа содержит дату григорианского календаря (с 01 января 0001 года) и время с точностью до секунды.
   catena
 
28 - 15.11.18 - 11:23
(24)Ну вот я не могу с ходу придумать задачу, где необходимо проверять на равенство дат. Обычно на больше-меньше, на заполненность и пр. На крайний случай - на вхождение в один период(месяц, год). А вот на равенство, по-моему, ни разу не проверяла.
   catena
 
29 - 15.11.18 - 11:24
(27)На 8.2.18 тоже воспроизводится)))
   Jackman
 
30 - 15.11.18 - 11:26
(13) ИМХО, лучше, чтобы в это поле в документе уже записывалась "округленная" дата, т.к. он выборку делает запросом и т.д., чтобы потом не заморачиваться. Но как сравнение - да, самый простой способ в (13)
   qq001
 
31 - 15.11.18 - 11:28
(25) Если бы это было сравнение, то без проблем, а мне нужно использовать метод ЗанятостьРабочихЦентров.НайтиСтроки(ПараметрыПоиска) и среди параметров поиска РабочийЦентр (на котором выполняется техоперация) и этот Период тупой. Я ж не знаю заранее разницу между датой из табличной части и датой, полученной запросом...
   RomanYS
 
32 - 15.11.18 - 11:29
При сохранении в базу дата документа округляется до секунд
    Док = Документы.АвансовыйОтчет.СоздатьДокумент();
    ТД = ТекущаяДата();
    сообщить(ТД - Дата(""+ТД))//0

    
    Док.Дата = ТД + 0.5;
    сообщить(Док.Дата - Дата(""+ТД))//0.5

    
    Док.Записать();
    
    ДатаИзБазы = Док.Ссылка.Дата;
    
    сообщить(ДатаИзБазы - Дата(""+ДатаИзБазы))//0
   RomanYS
 
33 - 15.11.18 - 11:30
(32) возможно влияет режим совместимости, запускалось на упп
 
 
   Малыш Джон
 
34 - 15.11.18 - 11:32
(31) приводи все данные(и ТЗ, и ПараметровПоиска) к секундной точности и будет тебе щасте
   Bigbro
 
35 - 15.11.18 - 11:35
я на равенство дат наступал на 7ке, уяснил что такое позиция документа, больше проблем не было.
   Eiffil123
 
36 - 15.11.18 - 11:36
(28) бывает таблицы нужно по датам соединять в запросах.

Заметил, что в регистре бухгалтерии добавили поле "длина уточнения периода". Может из-за этого теперь в дате миллисекунды завелись.
   qq001
 
37 - 15.11.18 - 11:36
(34) Это не ТЗ, а ТЧ. И там период уже хранится "как есть" с милисекундной точностью. Мне нужно выбрать строки из ТЧ методом НайтиСтроки (один из параметров поиска мой период) и затем в найденных строках поменять кое-что.
   RomanYS
 
38 - 15.11.18 - 11:36
(34) Ещё скажи, что все всегда так делают
(35) позиция и граница это другие типы
   RomanYS
 
39 - 15.11.18 - 11:37
(37) А откуда данные попали в ТЧ?
   catena
 
40 - 15.11.18 - 11:37
(36)Запрос приводит даты к секунде, я проверила) И тоже не могу вспомнить соединения по дате. По периоду было, а чтоб прям по дате?
   qq001
 
41 - 15.11.18 - 11:38
(39) План производства по сменам сформировался. Операции из техкарт попали в него в результате планирования.
   Малыш Джон
 
42 - 15.11.18 - 11:38
(38) "я сто раз так делал" (с)
(37) без разницы. Если ты хочешь искать данные в этой таблице, значит формат параметров поиска должен совпадать с форматом данных.
   qq001
 
43 - 15.11.18 - 11:39
(42) Ха-ха, ну по-любому :) Это ясное дело.
   Малыш Джон
 
44 - 15.11.18 - 11:40
(41) и ты хочешь сказать, что операции планируются с точностью до миллисекунд? Или их все таки можно округлять перед записью?
   Eiffil123
 
45 - 15.11.18 - 11:41
(40) а, т.е. получается, что это проблемы только даты, которая вычислена в оперативной памяти компьютера (причем именно вычислена, т.к. пользователь в поле с датой миллисекунды выбрать не может). Тогда не понятно назначение такого функционала в платформе.
   Малыш Джон
 
46 - 15.11.18 - 11:43
(45) я даже больше скажу: я не уверен, что эти доли секунд соответствуют действительности
   youalex
 
47 - 15.11.18 - 11:45
Сообщить(ЗаписатьДатуJSON('20180101' + 0.111, ФорматДатыJSON.JavaScript, ВариантЗаписиДатыJSON.УниверсальнаяДата));

выдает:
new Date(1514754000111)
   Eiffil123
 
48 - 15.11.18 - 11:45
(46) вот так работаешь более 10 лет с восьмеркой и узнаешь новое про примитивный тип Дата.
Хочется все сертификаты разорвать.
   qq001
 
49 - 15.11.18 - 11:50
(44) Да, это типовая конфа. Получается, с точностью до миллисекунд.
 
 Рекламное место пустует
   Малыш Джон
 
50 - 15.11.18 - 11:55
(49) на поддержке?

просто я не вижу другого способа, кроме как переделать процесс записи с округлением всех нужных данных до секунды.
   RomanYS
 
51 - 15.11.18 - 11:58
сделал аналогично (32) запись в реквизит документа и реквизит табличной части в пустой конфе (без режима совместимости): все даты округлились после записи в базу.
Как (0) удалось это обойти?
   Eiffil123
 
52 - 15.11.18 - 11:58
(50) так если запрос при получении данных округляет до секунд, то зачем при записи их округлять?
   ptiz
 
53 - 15.11.18 - 12:01
Да, тоже проверил на 8.3.13 - в справочнике при записи дата округлилась до секунды.
   Bigbro
 
54 - 15.11.18 - 12:03
(51) может какая то загрузка данных была нештатная?
   Bigbro
 
55 - 15.11.18 - 12:06
в (41) написано что план формировался автоматом. наверняка когда создавались документы бралось текущее время без всяких округлений и писалось с высокой точностью.
   RomanYS
 
56 - 15.11.18 - 12:06
(54) сделал Док.ОбменДанными.Загрузка = Истина
, ничего не изменилось.
Или думаешь ТС в файловую базу что-то пишет минуя платформу?
   RomanYS
 
57 - 15.11.18 - 12:07
(55) "бралось текущее время без всяких округлений" как это сделать? ТекущаяДата возвращает округленную
   RomanYS
 
58 - 15.11.18 - 12:08
(55) "писалось с высокой точностью" - вопрос тот же, Как?
   qq001
 
59 - 15.11.18 - 12:27
(55) Все планы производства так формируются, к сожалению, мне сложно найти место в конфе, где это описано, там вычисляется время исполнения технологической операции с конца, от даты окончания отнимается длительность операции и получается "Период" (то есть фактически дата начала исполнения).
   RomanYS
 
60 - 15.11.18 - 12:30
(59) Расчет может объяснить откуда взялись такие даты, но как тебе их удалось записать в базу?
Или у тебя строки ТЧ незаписанного документа?
   qq001
 
61 - 15.11.18 - 12:33
(60) ТЧ проведенного документа.
   RomanYS
 
62 - 15.11.18 - 12:38
(61) ХЗ. Ни у кого здесь не получилось записать дату с миллисекундами в базу. А у тебя ещё и режим совместимости с 8.2.
   qq001
 
63 - 15.11.18 - 12:39
(62) Конечно, Версия 8.2.13
   RomanYS
 
64 - 15.11.18 - 12:41
(63) может дата всё-таки не берется из записанного документа, а считается как в (59). Тогда всё объяснимо.
   qq001
 
65 - 15.11.18 - 12:55
(64) Моя доработка запускается, когда план уже полностью сформирован и проведен. Так что данные в ТЧ уже хранятся. Как - не могу ответить, с трудом читаю чужой программный код такой сложный, как в посменном планировании.

ВСЕМ СПАСИБО ЗА ПОМОЩЬ. Тип Дата для меня открылся с совершенно другой стороны :)
   Serg_1960
 
66 - 15.11.18 - 14:17
(62) Проверил на УПП в режиме совместимости 6.2.13. Чуда не произошло - при записи в базу миллисекунды отбрасываются.
(64) Предполагаю, что проблема автора кроется не в ТЧ документа, а в переменной "ПараметрыПоиска.Период".
   Serg_1960
 
67 - 15.11.18 - 14:19
Тьфу, не "6.2.13" разумеется, а "8.2.13". Проверял и в SQL, и в файловом режиме.
   RomanYS
 
68 - 15.11.18 - 14:21
(66) тоже думаю, что ТС как-то считает одну из дат. Но он не колется, говорит "из записанного документа"
   qq001
 
69 - 16.11.18 - 10:08
(68) Поскольку ЗанятостьРабочихЦентров[325].Период - ПараметрыПоиска.Период = 0,88, то миллисекунды есть в ТЧ в строке 325 в дате "Период".
Я очень хочу разобраться ради установления истины :)
   Bigbro
 
70 - 16.11.18 - 10:13
похоже там табличная часть пересчитывается в какой то момент, вопрос в какой?
   qq001
 
71 - 16.11.18 - 10:38
(70) Попробую объяснить суть работы. Это перепланирование, из ТЧ удаляются все техоперации старой детали (узла) и техоперации всех подчиненных деталей (узлов), из которых она состоит. Затем на их место планируется выпуск новой похожей детали, которую выбрал пользователь. У нас изготовление одной и той же детали возможно 5 способами (применяются разные технологии литья и разное оборудование, соответственно, разные спецификации и техкарты, а деталь на выходе та же). Только время ее изготовления будет другое.
И вот дата начала 1-2 из десятков новых операций при перепланировании иногда совпадает с датой начала какой-нибудь старой операции из плана (относящейся не к перепланируемой детали, а к какой-то другой, деталей в каждой готовой продукции около 1000, в каждой от 1 до 15 операций). Вот я и ищу эту старую строку в плане и от ее Периода хочу отнять секунду. Понятно, что совпадение дат начала операции на одном и том же рабочем центре - это ошибка планирования, поскольку оборудование уже занято и что-то другое одновременно на нем изготавливаться не может. Но я хочу пока просто обойти эту проблему, устранив совпадение дат, чтобы перепланирование заработало в общем, а потом уже решать мелкие проблемы. Потому что из тысяч правильных операций таких с совпавшими датами или пересекающимися периодами занятости рабочего центра всего 1-3.
Единственное, могу предположить, что при удалении старых строк из ТЧ по перепланируемой детали пересчитываются все оставшиеся строки ТЧ, но я после удаления делаю проведение документа, чтобы сведения о занятости рабочих центров попали в регистры, а сведения о занятости по удаляемой детали, наоборот, вычистились.
   НЕА123
 
72 - 16.11.18 - 10:44
(71)
объект перечитать
?
   RomanYS
 
73 - 16.11.18 - 10:46
(71) "после удаления делаю проведение документа" документ же после этого не перечитывается? Возможно ДокументОбъект продолжает содержать дробные даты, хотя в базу уже записаны округленные
   qq001
 
74 - 16.11.18 - 10:47
(73) Нет, после этого не перечитывается.
   RomanYS
 
75 - 16.11.18 - 10:47
(71) на самом деле чтобы избежать этого головняка просто округляй вычитаемую длительность до секунд
   qq001
 
76 - 16.11.18 - 10:48
(75) Уже сделано и все получилось :)
   dezss
 
77 - 16.11.18 - 11:22
(74) так попробуй перечитать
   RomanYS
 
78 - 16.11.18 - 11:24
(77) очевидно всё вылечится. Записать дату с миллисекундами (пока?) нельзя.
   exwill
 
79 - 16.11.18 - 11:31
(78) Потом, когда станет можно, возникнут те же проблемы с долями миллисекунд )))
   RomanYS
 
80 - 16.11.18 - 11:35
(79) там уже доли, точность - 0.1 мс
Непонятно зачем сейчас такой функционал, если толком его нельзя использовать. Но уже можно (при должном старании) поймать/создать баг как в (0)
   exwill
 
81 - 16.11.18 - 11:37
(80) MS SQL хранит даты с точностью до 100 наносекунд.
   RomanYS
 
82 - 16.11.18 - 11:39
(81) 1С ограничилась 100 мкс, но пока не хранит ;)
   exwill
 
83 - 16.11.18 - 11:45
(82) A PostgreSQL с точностью до 1 мкс.
   dezss
 
84 - 16.11.18 - 12:50
(79) не возникнет...когда они будут писаться, данные будут такие же, как и в тз
   dezss
 
85 - 16.11.18 - 12:50
(79) + тьфу...не понял тебя сразу...да, с долями милисекунд будут проблемы)
   Serg_1960
 
86 - 16.11.18 - 14:22
(80) Точность нужна, чтобы ошибки округления не набегали. В УПП, при расчете занятости тех.центров, те-же самые общие проблемы, что и (например) в бухгалтерии и в торговле. У одних копейки по строкам и сумме документа скачут, у других - цена в периоде :)
   Жан Пердежон
 
87 - 16.11.18 - 15:47
СП:
Дата (Date)
Описание:
Значения данного типа содержат дату григорианского календаря (с 01 января 0001 года) и время с точностью до 0,1 миллисекунды.
   dmitn
 
88 - 16.11.18 - 18:16
(47) выдает:
new Date(1514736000111)
   Serg_1960
 
89 - 16.11.18 - 22:11
(88) ТекущаяУниверсальнаяДатаВМиллисекундах()
   RomanYS
 
90 - 16.11.18 - 22:21
(89) это число причём целое, а здесь про  (24) и (87)
   youalex
 
91 - 16.11.18 - 23:34
(90) это, как я понял,  про возможное смещение относительно UTC.
А я написал про то, что во первых - это все же фича, раз оно реально может использоваться. Во вторых, возможно(сильно не факт) - эта фича появилась вместе с json.
   exwill
 
92 - 17.11.18 - 07:56
(91) Пляшут от количества байт выделяемых для этого типа данных. Далее определяются с тем, какие границы дат нужны. В результате получается точность. В 1С могли бы определить точность в 1 мс. Но тогда границы дат были бы не 4000 лет, а 40000 лет. Просто подумали - ну зачем нам это, давайте лучше точности добавим.
   Serg_1960
 
93 - 17.11.18 - 23:10
(90) Это про то, что универсальная дата изначально имела миллисекунды и это даже не секрет Полишинеля, а (47)  - "Первооткрывателям Америки посвящается" :)
   RedEchidna
 
94 - 19.11.18 - 04:43
(25) А если в сравнение попадут, скажем, даты '20130724132506.9' и '20130724132507.1' (запись условная)? Разница в 0.2 секунды, но при отбрасывании десятых долей разница уже одна секунда.
   craxx
 
95 - 19.11.18 - 05:05
(0) в запросе сделай НАЧАЛОПЕРИОДА(ТвоеВыражение,Секунда)
   craxx
 
96 - 19.11.18 - 05:22
(11) извращение, сродни тем, которые применял ныне покойный Андрей Романович Чикатило.
   catena
 
97 - 19.11.18 - 05:29
(95)Запрос и так приводит время к секундам.
   craxx
 
98 - 19.11.18 - 05:36
(97) есть куча других способов к секундам привести
Например:
Функция ДатаВремяДоСекунд(ДатаВремя)
   Возврат Дата(Год(ДатаВремя),Месяц(ДатаВремя),День(ДатаВремя),Час(ДатаВремя),Минута(ДатаВремя),Секунда(ДатаВремя));
КонецФункции
   catena
 
99 - 19.11.18 - 05:38
(98)Чем это лучше (11)?
   Serg_1960
 
100 - 19.11.18 - 12:48
(98) Можно проще. Подсказка: любая функция работы со значением типа "Дата" отрезает лишнее :) "НачалоМинуты(ДатаВремя) + Секунда(ДатаВремя)", "ДобавитьМесяц(ДатаВремя, 0)" и т.д.
  1  2   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует