First of all, openHAB is an opensource project. So any “poor functionalities” is because no one has yet volunteered their time to implement it. And like I said, your approach is not typical for users of openHAB.
Secondly, the “H” in openHAB stands for “Home”. It is not designed or architected to be an industrial control system. It therefore lacks the kind of redundancies and checks that one would put in place for an industrial system.
Thirdly the ‘A’ in openHAB stands for “Automation”, not “Control”. What you are trying to do is control your home automation system, not automate it. Rather than setting a set schedule, why not let your heating system work based on events? For example, when OH detects you are home and the sun has risen set to a certain temperature rather than a set start and stop time.
There is a known lacking in OH sitemaps of a calendar picker so that is part of the problem. But there is a larger effort to implement a scheduler and I think the maintainers are waiting on that to be done before tackling the addition of a calendar element to sitemaps.
So why do you have this requirement? What would happen if you just let the values update as you click the up and down arrows? You are just setting a time so it is not like you will put your heating system into some bad state while you are adjusting the times. And even if you were, there are simpler ways to handle this (e.g. keep using a proxy but use a Timer to not update the “real” element until the proxy remains unchanged for a certain period of time).
This is a Home Automation system that does not support entry of arbitrary data through the existing Sitemap based UIs. What exactly are you trying to protect against that you can’t do through properly defining your sitemap in the first place or through a Rule?
For an example of a typical way one deals with heating in openHAB see Heating Boilerplate - A Universal Temperature Control Solution with Modes.
First I would recommend reviewing the Design Pattern postings. There are plenty of constructs and approaches to doing all of this in a sane and simple manner. In particular, Design Pattern: Working with Groups in Rules, Design Pattern: Separation of Behaviors, and A State Machine Primer with HABlladin, the openHAB Genie.
Secondly, look into the JSR223 add-on which lets you write Rules in Jython, JavaScript, or Groovy.
Have you looked at HABPanel? It is more flexible in many ways and supports the use of custom widgets which may support the additions of the features you feel are lacking.
openHAB supports a full REST API so you can theoretically do pretty much everything outside of OH if you desired. It will be a whole lot of work but you could implement your own UIs and Rules Engine if that is your desire. I know of no one who posts on this forum who does anything like that though. There is also support for MQTT which lets you bridge between OH and something like Node-Red.
But to be clear, Rules are multi-threaded, Turing complete, and if coded using the Design Patterns I’ve sited above perfectly capable of producing generic, flexible, and reusable rules.
And again, I’ll ask, WHY? Why go through all of the effort of creating a transaction out of setting a time? Why set a time in the first place?