JS Scripting: date/time formatting?

3.3.0 Build 2351

I guess it’s time to learn Javascript. Something I’ve been putting off for years… LOL

Of course, the first thing I tried didn’t work. Such a basic thing. What am I missing?

I guess you could call this a Javascript question, but considering it gives the expected answer in my browser, but not in openHAB…

This should format the date using the specified options.

const date = new Date(2021, 4, 9, 12, 10, 30);
const options = {
      weekday: 'long',
      year: 'numeric',
      month: 'long',
      day: 'numeric',
      timeZoneName: 'long'
console.log(date.toLocaleDateString('en-US', options));

This is what I see in the openHAB log:

2021-12-24 10:12:39.744 [INFO ] [org.openhab.automation.script       ] - 2021-05-09

But isn’t it supposed to be this (in fact this is what I see when I run it in a browser):

Sunday, May 9, 2021, Eastern Daylight Time

Date is a JavaScript Date Object. JavaScript Date Reference

You are ware of this but I want future readers to see this explicitly said. You are not working with a Java ZonedDateTime like in Rules DSL.

Unfortunately I can’t help with this specific issue as that looks right to me.You could fall back to using a ZonedDateTime as a work around for now. All of Java is available to you when you need it.

Yes, quite right to point this out explicitly, as it could result in confusion. Thanks!

Yes, agreed, and it’s easy enough to do that. But…

I just don’t get how such a basic Javascript API can return something different than expected in the openHAB environment. As it was the very first thing I tried, it made me wonder if there is anything else that doesn’t behave as expected.

I would expect it to work too but have no experience with that.

The only major difference I’m aware of between GraalVM ECMAScript and “standard” is that in GraalVM we don’t have an event loop which is causing us some other problems (e.g. no Thread.sleep equivalent is possible since promise and await depends on that event loop).

Yeah, I saw that too. :sob: I decided to use setTimeout in place of Thread:sleep in a couple situations, but it’s not ideal since the code runs asynchronously.

        setTimeout(() => { 
            // Do stuff after 2 second delay
        }, 2000);

May as well use an OH timer. :wink:

1 Like

@mhilbush / @rlkoshak
I have found no downside in using setTimeout like this or do i miss here something?:

console.log("this is the start message")
setTimeout(() => {
  console.log("this is the 1sec message")
  setTimeout(() => {
    console.log("this is the 2sec message")
  }, 1000);
}, 1000);

Well, it’s not a true sleep, as it doesn’t block the execution of the main rule thread. So, it’s easy to get yourself into trouble by putting code after the setTimeout block, which would execute before the code in the setTimeout block. In other words, unless you’re very careful, it’s possible to create some unexpected behavior in your rules…

Would this function work?
Somebody has posted a script with this function in it and says that it works properly.

That works in Nashorn JS (ECMAScrpt 5.1). it the throws an exception in JSScripting. Messing with Threads in GraalVM JS is strictly forbidden.

1 Like

@rlkoshak : I do not know if you already know but you can use Thread::sleep with the JSS addon:


Hope it helps somehow.

Something must have recently changed in the add-on. As of the last milestone at least it indeed seems to work.