OH4 timestamps without seconds and miliseconds behave differently?

using OH4.0.3 rules with Javascript v11.

I run the following script:

var jetzt = time.LocalDateTime.now();
console.info("INFO: jetzt: " + jetzt);
var SpaetStart = jetzt.withHour(13).withMinute(0).withSecond(0).withNano(0);
console.info("INFO: SpaetStart = " + SpaetStart);
items.getItem("EMS_SpMaStartpunkt").postUpdate(SpaetStart.toString());

the logs:

2023-10-09 19:40:53.865 [INFO ] [nhab.automation.script.ui.test262_11] - INFO: jetzt: 2023-10-09T19:40:53.862
2023-10-09 19:40:53.869 [INFO ] [nhab.automation.script.ui.test262_11] - INFO: SpaetStart = 2023-10-09T14:00
2023-10-09 19:40:53.872 [INFO ] [nhab.automation.script.ui.test262_11] - INFO: Spätester Start wird gesetzt auf:  2023-10-10T14:00

2023-10-09 19:40:53.876 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EMS_SpMaStartpunkt' changed from 2023-10-08T14:00:00.000+0200 to 2023-10-10T13:00:00.000+0200

If I then get the state of the item:

var SpaeterStart = time.toZDT(items.getItem("EMS_SpMaStartpunkt").state);
console.info("Aus dem item: " + SpaeterStart)

the output:

2023-10-09 19:42:24.204 [INFO ] [rg.openhab.automation.script.ui.test] - Aus dem item: 2023-10-10T13:00+02:00

But: if I use the API Explorer/Swagger:
grafik

I’m not sure, but I think, this was different on OH3? But does it really matter or is it just a matter of displaying?

This is kind of over done. The following is much simpler.

var jetzt = time.toZDT().toLocalDateTime();
console.info("INFO: jetzt: " + jetzt); // you are already telling it to log as INFO, you don't need to add "INFO" to the log statement itself.
var SpaetStart = time.toZDT("13:00").toLocalDateTime();
console.info("INFO: SpaetStart = " + SpaetStart);
items.EMS_SpMaStartopunkt.postUpdate(SpaetStart);

Immediately from the same rule? If so then there is no guarantee that the update has made it to the rule yet. It does take some time for an update to process. If this worked for you in the past, it was a trick of the timing.

It does probably matter since 13:00:00.000+0200 is not the same as 14:00:00.000+0200. But it’s not clear what you are looking at here. You’ve also done some switching between LocalDateTime and ZonedDateTime. Maybe something is getting messed up there?

I generally advise sticking to ZonedDateTime unless there is a real reason not to. There is no reason not to here.

var jetzt = time.toZDT();
console.info("INFO: jetzt: " + jetzt); // you are already telling it to log as INFO, you don't need to add "INFO" to the log statement itself.
var SpaetStart = time.toZDT("13:00");
console.info("INFO: SpaetStart = " + SpaetStart);
items.EMS_SpMaStartopunkt.postUpdate(SpaetStart);
1 Like

First of all, thanks again for helping me out with the timestamps. I’m still not firm enough with the timestamp-variants and stuff. And yes, I’d like to stick to one (ZDT if it is).

no, from another rule another time… That’s what I found strange…

no, sorry. the difference is only the missing seconds and milliseconds while reading the item’s state within OH4. My impression was, in OH3 I got the whole stuff including seconds/msec.
PS: I mixed up with my test item-updates. It’s not the 13/14h difference… I adjusted my initial post. sorry for the confusion.

yes! Thanks a lot!

Definitely look at the table in the JS Scripting Docs that explains how time.toZDT() works. It saves a ton of code and frees you from just about any conversions you might have. No matter what you pass it, if it somehow makes sense, you will get a ZonedDateTime back suitable for use in comparisons, to create Timers, and to update Items with.

Also look at some of the additions JS Scripting has added to ZonedDateTime and the time library. I particularly find isBetweenTimes() to be useful as well as toToday().