Assuming that it is current 2020:08:31T14:48:00.000, when you call now.plusMinutes(5)
you are getting a DateTime that represents exactly 2020:08:31T14:53:00.000.
Anything that uses now.plusX
is calculating an exact point in time. It’s effectively calculating the exact millisecond in the future that will be plusX from now.
In the alarm clock examples, you may see something like now.withTimeAtStartOfDay.plusHours(H).plusMinutes(M)
. In that case the withTimeAtStartOfDay
takes now to midnight today, the plusHours adds H hours from midnight today and the plusMinutes adds M minutes to that to get an exact hour and minute for today.
Alternatively you might see DateTime(H, M, 0)
which creates a new DateTime with today for the date and H for the hours and M for minutes and 0 for the seconds. But again, you end up with an exact point in time for today.
It is actually impossible to schedule a Timer with anything but an exact point in time when it’s to run.
Again, this is why you need to recreate the timers every day. Also note that cron triggered rules do the exact same thing. It looks at the cron expression and creates a Timer to run the rule at the time represented by the expression. It’s the exact same code that handles both.
Depends on your definition of easier to handle. If you are looking to have a rule to create a rule with a cron expression as described in the OP than no, I do not agree at all. It’s far easier to create a scriptUnloaded function to cancel your Timers and either put in a scriptLoaded function or a System started triggered rule the recreation of the Timers. System started is particularly useful for cases where the time is defined by an Item or Items as the exact same rule that runs when the Item(s) changes can be triggered by a System started trigger and you are done. Restarts are automatically handled with no effort at all.
The amount of time the Timer is scheduled for is irrelevant. I have Timers that live for days at a time and never fail to trigger.
The only thing that is easier to handle is if you in fact do have a cron triggered rule with a hard coded start time. In that case it’s easier because you don’t have to do any of the book keeping to make sure the Timer get’s cancelled and recreated properly. But that isn’t what you were asking about in the OP. You were asking for a way to create a rule with a cron trigger that is based on the value of some Item. You’ve replaced a bunch of relatively easy (and with some of the libraries I and others have written becoming even easier) with an bunch of complicated rule management. At best you’ve replaced one set of complicated stuff with another set of complicated stuff without actually making anything simpler.
I bet you will find that if you move to Jython and make sure to write a scriptUnloaded function for all your modules where Timers are created to cancel all the running Timers you will find your errors (and therefore misimpression that they are unreliable) go away.