Никогда даже в мысли не приходило, что кто-то из ОВЕН полазил в библиотеке STADARD.LIB и что RTC из ее состава привязана к аппаратным часам, поэтому и претензия к разработчикам контроллера ОВЕН а не разработчикам CoDeSys, т.к. ОВЕН заявил о полной поддержке библиотеки STANDARD.LIB, а в действительности это не реализовал, что уже признал и пообещал исправить (скорее всего будет исправлена документация).
А. т.к. ОВЕН признал свою ошибку, поэтому не вижу дальнейшего смысла рассуждать на эту тему и писать о зоне ответственности...
В нашей жизни практически все субъективно, т.к. каждый индивидуум смотрит на все через свою неповторимую призму (которую формируют знания, жизненный опыт и т.д.), поэтому и говорят:-"Сколько людей - Столько мнений". К сожалению ни одной темы посвященной наработке времени не читал, т.к. реализация этого банально проста, и вопросов у меня не вызывала. А RTC был выбран по следующим причинам: 1) Отсутствие влияния перевода аппаратных часов (т.е. это не нужно отслеживать); 2) Отсутствует возможность влияния состояния батарейки аппаратных часов либо ее отсутствие; 3) Не требуется ничего дополнительно, часы идут только во время работы контроллера; 4) Простота получения наработки в часах, т.е. минимум вычислений (просто делаем перевод DT_TO_UDINT и делим на 3600).
И кстати, реализация у ОВЕН функционального блока RTC из библиотеки STANDARD.LIB хоть и не совсем корректна, но если производить инициализацию RTC с задержкой в 30 секунд от начала исполнения программы, то функциональный блок работает вполне нормально (по крайной мере никаких скачков в течении 3 часов работы не наблюдалось)...