The method getZonedDateTime() from the type DateTimeType is deprecated

Setup, Configuration and Use Scripts & Rules
1

oH 4.3.0.M5

if (now.isAfter((Astro_DaylightStart_Time.state as DateTimeType).getZonedDateTime())) {...

I use this statement and it works fine, but I get for every occurrence the topic info in the log. What is the correct instruction for the future? I can only find this way to compare with now.

2

Hi, try this

(Astro_DaylightStart_Time.state as DateTimeType).zonedDateTime

Greets

3

Thanks for the quick reply, but I get the same message.

4

Same for me.
This is due a change in DateTimeType.
@laursen that is for you.

5

Thanks for reporting this.

Please try this:

if (now.isAfter((Astro_DaylightStart_Time.state as DateTimeType).getZonedDateTime(ZoneId.systemDefault()))) {...

The ZoneId parameter is the time-zone for which you want the ZonedDateTime.

The reason is that DateTimeType no longer contains time-zone, so this will have to be applied. The deprecated method getZonedDateTime() uses ZoneId.systemDefault() internally. However, this can be misleading, since it is no longer the time-zone used when creating the DateTimeType object, because that time-zone is now discarded.

Please see the full explanation here:

I didn’t anticipate that Rules DSL would show these deprecation warnings. Can you confirm that this is only shown when loading the rule, and not when executing it?

I’m now considering a few actions:

  • Add an upgrade note with a deprecation notice that will be shown when upgrading.
  • Ask core maintainers to add a label to the PR so that it will be included in the final release notes.
  • Reconsider if the method should be deprecated:
    • in 4.3
    • in 5.0
    • at all

I think deprecation has both advantages and disadvantages.

3 Likes
6

Thanks, that was the solution.

7

Thx, fixed it for me, too :+1:

8

For me it was only shown when saving/loading the rule, not when executing:

2024-12-09 19:26:34.211 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'energy.rules', using it anyway:
The method getZonedDateTime() from the type DateTimeType is deprecated
9

correctly

10

I guess a better alternative would be to use Instant, creating now from Instant? isAfter is available also on Instant? Do we have a method to get Instant from DateTimeType?

11

Yes, you are right. I’m getting rusty in DSL, so I’m not sure how to get now as Instant, maybe simply Instant.now() as in Java?

Yes.

Yes, see:

13

This seems to work:

	var before = Instant.now().minusSeconds(10)
	var now = Instant.now()
	if (now.isAfter(before)) {
	    logInfo("test", "now is after before")
	}
	if (before.isBefore(now)) {
		logInfo("test", "before is before now")
	}

So the original code could be rewritten to:

if (Instant.now().isAfter((Astro_DaylightStart_Time.state as DateTimeType).instant)) {...

as suggested by @Lolodomo. This would be less error-prone since time-zone is taken out of the equation.

14
15

I just upgraded to M5 and ran into this issue. I also found that plusMinutes and plusHours have also have been deprecated requiring me to extensively modify my rule sets. I believe that this is a Java 8 implementation, but for those of us that aren’t up-to-date with our Java, it can be a surprise. You may want to make note in the documents that these functions have been replaced with the more generic plus(number,chronoUnit) i.e. plus(2,HOURS) and that only plusSeconds() has been retained.

16

Can you provide a bit more information, for example some rule code and how you see that it has been deprecated?

17

For example the code

myTimer2=createTimer(Instant.now().plusMinutes(4),

generated the following log errors
Script execution of rule with UID 'hvac_mode_change-1' failed: 'plusMinutes' is not a member of 'java.time.Instant';

18

plusMinutes simply does not exist on java Instant.

1 Like
19

As @Lolodomo mentioned, this is not a deprecation warning, this has never worked. Did you refactor your rule recently?

You can fix it by reverting to ZonedDateTime:

myTimer2=createTimer(now.plusMinutes(4),

But just to be clear, none of this is related to the topic for this thread.

20

@Lolodomo you are correct as far as I can tell, but my point is that by deprecating getZonedDateTime, there is a cascading effect and many rules may potentially be affected. The user community should be made aware of this in the documentation. I for one had many rules that used getZonedDateTime with plusHours and plusMinutes that I had to change. That is the price of progress, not a huge issue, but I wasn’t aware of this requirement. Just an awareness for others.

21

How does it cascade? The minimal solution is to replace getZonedDateTime() by getZonedDateTime(ZoneId.systemDefault()). In some cases you might want to take a step further and simplify rules like suggested here: The method getZonedDateTime() from the type DateTimeType is deprecated - #10 by Lolodomo - but this is not required.

Also it’s worth mentioning that all rules will still work without any changes, but there will be a lot of deprecation warnings logged when the rules are loaded.

Can you point towards some documentation that should be updated, then I will happily create a PR for that. :slight_smile: