zonedDateTime != java.time.ZonedDateTime

Setup, Configuration and Use Scripts & Rules
1

Running some experiments with OH 2.4 Rule scripts, trying to understand the limits of DateTime and ChronoUnit methods/calculations. In particular I’m looking at the .until() method - which only works on java.time.ZonedDateTime classes.

Can someone clarify what’s going on with this rule (I’ve clearly have a fundamental miss understanding):

rule "Test zonedDateTime"
when 
  Item GF_Test_Rule changed from ON to OFF
then
    var d1 = Virtual_DateTime_1.getStateAs(DateTimeType).zonedDateTime
    logInfo(LogSubpackage, "d1.class = '{}'", d1.class)
    var ZonedDateTime d2 = parse("2020-01-06T00:00+10:00")
    logInfo(LogSubpackage, "d2.class = '{}'", d2.class)
end

‘Virtual_DateTime_1’ is an Item of type DateTime.

When this runs the first logInfo prints:
[INFO ] […] - d1.class = ‘class java.time.ZonedDateTime’

And the second generates an error:
[ERROR] […] - Rule ‘Test zonedDateTime’: ‘class’ is not a member of ‘ZonedDateTime’

Clearly a ZonedDateTime declaration isn’t the same as assigning ZonedDateTime type, or ZonedDateTime != java.time.ZonedDateTime

So why are they behaving differently?

2

Try using this instead…

var d2 = new DateTimeType("2020-01-06T00:00+10:00").zonedDateTime
3

Thanks Scott.

When I try that d2.class returns ‘class java.time.ZonedDateTime’.

Does anyone know why the declaration ‘var ZonedDateTime’ doesn’t product the right type?

4

This is no good…

var ZonedDateTime d2 = parse("2020-01-06T00:00+10:00")

You’re trying to cast d2 as a ZonedDateTime, but you are assigning it to an org.joda.time.DateTime. On top of that, ZonedDateTime is not included in the default scope, so you would need to import it. Put it all together and the rules DSL validation has a hiccup.

How to prevent this? In the rules DSL, never cast unless you absolutely need to.

5

Thanks Scott - I suspected that parse() wasn’t generating the right type.

It would be great if we could ignore types (I know this is the goal for DSL), but pretty much anything interesting in DSL ends up going down a rabbit hole of classes, types and casting.

If I can understand how things are working internally and come up with some good guidelines, then I’ll publish the results for everyone.