DateTime Conversion after Update to 4.3.0

WeRo · December 22, 2024, 4:04pm

After the Update tonight this rule doesn’t work anymore:

val sunsetend = ((Sunset_End.state as DateTimeType).getZonedDateTime())
val daylstart = ((Daylight_Start.state as DateTimeType).getZonedDateTime())
Sunset_End_Rule.postUpdate(sunsetend.minusDays(1).toString)
Daylight_Start_Rule.postUpdate(daylstart.toString)

Sunset_End_Rule and Daylight_Start_Rule are both items of DateTime type.

The error message is:
Cannot convert ‘2024-12-22T16:29+01:00[Europe/Berlin]’ to a state type which item ‘Sunset_End_Rule’ accepts: [DateTimeType, UnDefType].
Cannot convert ‘2024-12-23T08:27+01:00[Europe/Berlin]’ to a state type which item ‘Daylight_Start_Rule’ accepts: [DateTimeType, UnDefType].

hmerk · December 22, 2024, 4:12pm

You have missed the deprecation warning.
Please check here

WeRo · December 22, 2024, 4:27pm

It is still the same error using this statement as suggested:

val sunsetend = ((Sunset_End.state as DateTimeType).getZonedDateTime(ZoneId.systemDefault()))
val daylstart = ((Daylight_Start.state as DateTimeType).getZonedDateTime(ZoneId.systemDefault()))

laursen · December 22, 2024, 9:38pm

This is not related to the deprecation of getZonedDateTime(). What is the source of the state for Sunset_End and Daylight_Start?

My theory is that the state might have been updated without explicit time-zone ID provided and as a result toString() would return “2024-12-22T16:29+01:00” prior to 4.3. Now, the time-zone is provided as ZoneId.systemDefault() and thus you get “2024-12-22T16:29+01:00[Europe/Berlin]”, which I believe DateTimeType is not able to parse. I would like to confirm this.

You could try this to parse it as Instant rather than ZonedDateTime with time-zone ID:

val sunsetend = ((Sunset_End.state as DateTimeType).getZonedDateTime(ZoneId.systemDefault))
val daylstart = ((Daylight_Start.state as DateTimeType).getZonedDateTime(ZoneId.systemDefault))
Sunset_End_Rule.postUpdate(sunsetend.minusDays(1).toInstant.toString)
Daylight_Start_Rule.postUpdate(daylstart.toInstant().toString)

laursen · December 22, 2024, 11:44pm

For reference:

github.com/openhab/openhab-core

Enhance `DateTimeType` to parse `ZonedDateTime` with time-zone ID

openhab:main ← jlaur:datetimetype-parse-zoneddatetime

opened 11:40PM - 22 Dec 24 UTC

jlaur

+13 -45

This DSL rule: ```java rule "Test" when Item Test changed to ON then … var zoned = ZonedDateTime.parse("2024-12-22T16:29+01:00") logInfo("zoned to item", zoned.toString) TestDateTime.postUpdate(zoned.toString) zoned = (TestDateTime.state as DateTimeType).getZonedDateTime() logInfo("zoned from item", zoned.toString) TestDateTime.postUpdate(zoned.toString) end ``` generates the following output in 4.3: ``` 2024-12-23 00:27:00.168 [INFO ] [nhab.core.model.script.zoned to item] - 2024-12-22T16:29+01:00 2024-12-23 00:27:00.169 [INFO ] [ab.core.model.script.zoned from item] - 2024-12-22T16:29+01:00[Europe/Copenhagen] 2024-12-23 00:27:00.170 [WARN ] [b.core.model.script.actions.BusEvent] - Cannot convert '2024-12-22T16:29+01:00[Europe/Copenhagen]' to a state type which item 'TestDateTime' accepts: [DateTimeType, UnDefType]. ``` Until 4.2 this rule worked, because `getZonedDateTime()` returned the same `ZonedDateTime` as provided when creating the `DateTimeType`. Since it didn't contain time-zone ID (e.g. "2024-12-22T16:29+01:00"), `DateTimeType.parse` would then be able to parse it. Now, it contains the time-zone ID (e.g. "2024-12-22T16:29+01:00[Europe/Copenhagen]"), which `DateTimeType.parse` is not able to parse (and never was). To make this rule compatible I would propose to add support for parsing a full `ZonedDateTime` string that includes time-zone ID. If this is accepted, I think it should also be cherry-picked into 4.3.x for immediate value. i.e. to fix rules that might have been broken by 4.3. By the time we reach 5.0 users would otherwise have been forced to refactor their rules already. See https://community.openhab.org/t/datetime-conversion-after-update-to-4-3-0/161053/1 Regression of #3583

WeRo · December 23, 2024, 6:29pm

That’s it!
toInstant() at the postUpdate command was the missing part.
Many thanks!!

laursen · January 12, 2025, 9:34pm

I did not get this confirmation, but with 4.3.2 (which was just released), DateTimeType can now handle a string like “2024-12-22T16:29+01:00[Europe/Berlin]”, so the original rule posted here should now work.