I’m no Java expert, but isn’t the whole point of using ZonedDateTime that you don’t have to worry about these things? AFAIK ZonedDateTime handles DST by itself.
It does if you let it. At it’s core, ZonedDateTime stores the time as the number of milliseconds (or perhaps nanoseconds) since 1970-01-01T00:00:00 GMT. Everything else that you see is the result of a calculation, a very complicated calculation.
The code that I have to move the time to the next day is skipping that calculation that handled DST change overs.
Date times are really complicated.
Not wanting to stir things up, but the DSL version I use for “production” flawlessly managed the DST transition. I guess exactly because the times are hard-coded and the system time was adjusted by the OS. So I guess that the KISS principle has its advantages sometimes 
(I use the DSL version mainly because my Openhab still messes up the ephemeris settings on every restart, which really throws a wrench into the gears of the JS version)
It does the calculation to move the time to today in an awkward, and complicated, and hard to understand manner. It is not at all clear why we need to jump to midnight on the next day and then subtract the number of hours between the hour you want and midnight. Those lines of code actually violate KISS, which is why I changed it.
As I’ve said before, anyone is welcome to continue to use the Rules DSL version. But I’m not going to support it going forward.
I agree with you on that one…
Hi, i am getting an error after installing the javascript in openHAB 3.0.1 and running the rule manually:
2021-03-20 12:19:04.657 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID '0f323269e8' failed: <eval>:277:0 Expected } but found eof
^ in <eval> at line number 277 at column number 0
What I have done so far:
- installed and tested timer_mgr and time_utils
- created the items like the example
- created a new rule
- opened the “code” tab
- pasted the YAML there (raw code)
- save
- manually run the rule by clicking the play icon.
TimeOfDay stays NULL. What am I missing?
While it’s not clear, it is necessary twice a year.
Today might be the clock change day, example when you do your calculation at 01:00 for the day ahead the damn clock might change in an hours time. Scheduling +7hrs is not guaranteed to hit 08:00 local time.
Working backwards from next midnight (which the datetime system will calculate based on localtime) is a circumvention.
Double check that you copied the whole time. That error indicates you might have missed the last line of code somewhere.
The error indicates a missing closed bracket.
I didn’t mean to imply that I didn’t understand why the Rules DSL was written that way. But assumed, falsely it works appear, that if I had 5:00 pm the day before the changeover, if I moved the date part to the day after the changeover by changing the date (not just adding a day), that it would keep the time 5:00. In other words chasing the date would cause ZonedDateTime to account for the change. I already know it can’ account for dst. But it’ll looks like it’s doesn’t.
So what I’ll probably do is recreate the DT to include the hh:mm:ss as well which should force dst calculation.
I checked that several times.
I copy & paste this content in my rule, using the “code” tab of Main UI, correct?
https://raw.githubusercontent.com/rkoshak/openhab-rules-tools/main/ephem_tod/javascript/ephemTimeOfDay.yml
I get the same error twice. I have searched for a missing bracket but can’t find it.
Hmm, you’re already using the raw version, which usually works.
My script is exactly 333 lines, if that helps.
I have found the missing bracket, but its missing in the raw file as well.
Looking up the line, one moment.
edit: function verifyMetadata, there is a bracket missing at the end. I added the bracket and updated the default values, now it seems to work without errors.
You’re right, there’s one missing in the raw file right after “return null;”
If one of you can submit a pr I’ll approve it. Otherwise it will probably be Monday.
1 Like
Merged. Thanks! I’ll need to look into how the error ended up in there in the first place later. There GitHub app is pretty handy. 
Clearly my code review skills need brushing off.
I have installed the rules (javascript). Set up some some points in my model (like: Default_Morning in group TimesofDay), but I can’t figure out where I have to add the metadata. I came form text files in Openhab 2, but want to transfer completely to the MainUI. I have read a couple of times through the readme file and this topic, but can not find a solution. Any hint where I have to look ?
Navigate to the Item in the Items Settings page, or from the model or how ever you choose. There are lots of ways to get to an Item’s page.
Settings → Items → Search for “Default_Morning”
as one example.
One there you will see a n “Add Metadata” option near the bottom of the page. Click in then select “Enter Custom Metadata”. Enter etod as the namespace and fill out the values as desired based on the instructions. For example:
value: DAY
config:
type: default
Hi Rich,
I’m using the javascript version of the rule within openHAB3.1M2.
Worked fine so far …
It seems I have an issue with recently started daylight saving time 
All fixed timesOfDay (means: not provided e.g. by Astro binding), as default_Bed, default_Morning, ... now have an offset of one hour.
Yes, the clock on the Linux OS is set correctly to use DST and even inside openHAB other dynamic set datetime items (e.g. by a timestamp link profile) show the right time, and as said - the Astro-provided time is o.k. too…
Seems, that the generated timers for the fixed transition times simply fire one hour to late while not considering the DST offset.
Any idea?