Ну вот по закону "подлости". То косяк проявлялся везде и всюду, то исчез без следа...
- а был ли мальчик?..
- нет, ну оно конечно... может просто звезды не сошлись... или разошлись?.. всяко бывает 
- ну а если серьезно, то пока не выяснено при каких обстоятельствах это проявляется, то и баг-репорт нормально не оформить... и работать в LO придется как на минном поле...
Пользователь добавил сообщение 28 Декабря 2019, 05:52:47:
- а то, Dixi257, что проблема обсуждается в определенных кругах, на самом деле, мало успокаивает... поле то все еще остается заминированным 
Кстати, автор по второй ссылке указывает на те же самые требования:
Здесь я лично прихожу к выводу, что необходимо вводить дополнительные функции округления уже на основании видимых данных, ведь куда проще записать функцию типа =roundtimeup(Xt) и добиваться нужных результатов.
Собственно, разработчики и тестировщики уже активно обсуждают эту проблему.
https://bugs.documentfoundation.org/show_bug.cgi?id=127477
https://bugs.documentfoundation.org/show_bug.cgi?id=127334
Я тоже могу обсуждать что угодно, хоть подвязки любимой женщины своего врага но всерьёз я не приму это, пока не увижу правдивый результат. Вот давайте тогда спросят у меня что нужно получить, а я отвечу, что мне нужно видеть то, что отвечает правилам арифметики. Если мы складываем целые минуты в стандарте ЧЧ:ММ:СС+ЧЧ:ММ:СС то соответственно я планирую получить арифметическую сумму часов, минут и секунд с правилами перехода через 59 секунд. Ни более, ни менее и если я складываю: 1:30+0:30 я ожидаю 2:00, а не 1:59:59 в бесконечном периоде, потому что чисто арифметически переход в следующий час произошёл потому что мы прибавили к 30 минутам 30 минут, помните правила сложения в столбик, 0 пишем 1 в уме прибавляем в следующему разряду, а не 29 минут и 59 секунд, и это в лучшем случае.
Это даже не комбинаторика, а элементарная арифметика на счётных палочках.
То-есть появляется неприкрытый риск ошибки, а трудовая инспекция, когда будет проверять документы по жалобе работяги на нарушения режима труда и отдыха или не дай бог аварии, увидит, что результаты не соответствуют расчётам, и что ему нужно было приступить к работе в 8 часов 10 минут, а не в 8 часов 9 минут, поверьте, кое-где это юридически и даже финансово важно, от секунды может зависеть, получите ли вы 13-ю зарплату или -100% премии.
Мы уже толкуем о профессиональном применении софта.
Благо, моя работа учебная, но преподаватель разницу заметит только взглянув на результаты, он не дурак вообще-то.
И процитирую перевод части текса после перехода по ссылкам:
электронными таблицами (включая LibreOffice Calc до версии 6.0.4.2), и все они смогли найти правильные значения минут. Пока это работало, как ожидалось, мне было все равно, как это было достигнуто. Я предполагаю, что они внутренне округлили значения с плавающей запятой до некоторого внутреннего временного разрешения, прежде чем интерпретировать их как время и / или дату. Если это разрешение выбрано так, что оно на несколько порядков выше ошибок округления с плавающей запятой, эти ошибки будут влиять на результат только в крайних случаях. Язык программирования Java выполняет вычисления даты / времени на основе целых чисел в миллисекундах, чтобы вообще избежать проблем округления. Закрытие этой ошибки как «NOTABUG» говорит мне, что стандарты качества LibreOffices позволяют алгоритмам вычисления времени давать ноль или одну минуту с равной вероятностью при вычитании, например, две минуты из трех минут.
Второе: эта проблема затрагивает все функции такого рода. Ошибка округления в диапазоне менее миллисекунд может привести к тому, что функция year вернет неправильный год. Основная проблема заключается в том, что обычно учитываются целые числа единиц времени (годы, месяц, дни, часы, минуты и секунды), и поэтому расчеты могут быть точными. Однако LibreOffice использует представление времени, которое не может гарантировать точное представление единиц времени, часов, минут и секунд.
Третье: я больше не могу доверять результатам расчетов даты / времени LibreOffices. Любые устаревшие электронные таблицы, содержащие такие простые расчеты времени, дадут неверные результаты, если открыть их в последних версиях Calc. Хуже всего то, что в пользовательской документации не указано, как Calc предназначен для решения проблем, связанных с его временным представлением, и, очевидно, это намерение время от времени меняется. Поэтому я не могу знать, как использовать функции вычисления даты / времени таким образом, чтобы будущая версия Calc возвращала те же результаты, даже если я предполагаю, что эти функции реализованы правильно.