[SOLVED] HABPanel sluggish

laursen · December 29, 2024, 8:50pm

This method signature has changed, see:

ZoneId has been added as last parameter.

This is related to:

github.com/openhab/openhab-core

[core] Switch `DateTimeType` to `Instant` internally for consistent time-zone handling

openhab:main ← jlaur:2898-datetimetype-instant

opened 10:09PM - 29 Apr 23 UTC

jlaur

+337 -252

Proposal for switching `DateTimeType` to use `Instant` internally rather than `Z…onedDateTime`. This will effectively discard time-zone information from the _source_ of the `DateTimeType` and leave it to consumers to apply time-zone at the moment of _presentation_, according to the configured time-zone in openHAB regional settings or in the browser. Configured time-zone is now applied for: - REST API - SSE item state events - Item UI registry (affecting e.g. sitemaps) Consequential changes because `DateTimeType` is now "zone-less": - Parameter `timezone` for `TimestampOffsetProfile` has been removed. openhab/openhab-docs#2403 has been prepared. - Methods `toZone`, `toLocaleZone` and `getZonedDateTime` have been marked as deprecated and all usages have been refactored. I would suggest to remove them in 5.0 (or maybe even before when all bindings are refactored, see openhab/openhab-addons#17725). - Method `getZonedDateTime(ZoneId)` has been introduced for convenience. The following demonstrates the difference between old and new behavior. REST API calls are for `http://localhost:8080/rest/items/DateTimeTest` and the returned `state` is shown in the comparison table: ```json { "link": "http://localhost:8080/rest/items/DateTimeTest", "state": "2024-10-31T21:00:00.000+0100", "stateDescription": { "pattern": "%1$tY-%1$tm-%1$td %1$tH:%1$tM:%1$tS", "readOnly": false, "options": [] }, "editable": true, "type": "DateTime", "name": "DateTimeTest", "label": "", "category": "", "tags": [], "groupNames": [] } ``` Updates are made in Karaf using commands like: ```shell openhab:update DateTimeTest 2024-10-31T21:00:00+01:00 ``` | Step | Before | Now | |------------------------------------------|------------------------------|----------------------------------| | System time-zone: Europe/Copenhagen | | | | Set openHAB time-zone: Europe/Copenhagen | | | | Update to: 2024-10-01T20:00:00Z | | | | Observe REST API result | 2024-10-01T20:00:00.000+0000 | 2024-10-01T**22:00:00.000+0200** | | Observe /settings/items/ | 2024-10-01T20:00:00.000+0000 | 2024-10-01T**22:00:00.000+0200** | | Observe /settings/items/DateTimeTest | 2024-10-01 22:00:00 | 2024-10-01 22:00:00 | | Observe sitemap | 2024-10-01 22:00:00 | 2024-10-01 22:00:00 | | Update to: 2024-10-31T20:00:00Z | | | | Observe REST API result | 2024-10-31T20:00:00.000+0000 | 2024-10-31T**21:00:00.000+0100** | | Observe /settings/items/ | 2024-10-31T20:00:00.000+0000 | 2024-10-31T**21:00:00.000+0100** | | Observe /settings/items/DateTimeTest | 2024-10-31 21:00:00 | 2024-10-31 21:00:00 | | Observe sitemap | 2024-10-31 21:00:00 | 2024-10-31 21:00:00 | | Update to: 2024-10-31T21:00:00+01:00 | | | | Observe REST API result | 2024-10-31T21:00:00.000+0100 | 2024-10-31T21:00:00.000+0100 | | Observe /settings/items/ | 2024-10-31T21:00:00.000+0100 | 2024-10-31T21:00:00.000+0100 | | Observe /settings/items/DateTimeTest | 2024-10-31 21:00:00 | 2024-10-31 21:00:00 | | Observe sitemap | 2024-10-31 21:00:00 | 2024-10-31 21:00:00 | | Set time-zone: US/Alaska | | | | Observe REST API result | 2024-10-31T21:00:00.000+0100 | 2024-10-31T**12:00:00.000-0800** | | Observe /settings/items/ | 2024-10-31T21:00:00.000+0100 | 2024-10-31T**12:00:00.000-0800** | | Observe /settings/items/DateTimeTest | 2024-10-31 21:00:00 | 2024-10-31 **12:00:00** | | Observe sitemap | 2024-10-31 21:00:00 | 2024-10-31 **12:00:00** | | Update to: 2024-10-31T**12:00:00-0800** | | | | Observe REST API result | 2024-10-31T12:00:00.000-0800 | 2024-10-31T12:00:00.000-0800 | | Observe /settings/items/ | 2024-10-31T12:00:00.000-0800 | 2024-10-31T12:00:00.000-0800 | | Observe /settings/items/DateTimeTest | 2024-10-31 21:00:00 | 2024-10-31 **12:00:00** | | Observe sitemap | 2024-10-31 21:00:00 | 2024-10-31 **12:00:00** | As it can be seen from the table, we now have consistent results. Example DSL rule: ```java var dt = ZonedDateTime.of(2024, 4, 26, 0, 0, 0, 0, ZoneId.systemDefault()) DateTimeTest1.postUpdate(new DateTimeType(dt)) DateTimeTest2.postUpdate(new DateTimeType(dt.toInstant().atZone(ZoneId.of("UTC")))) DateTimeTest3.postUpdate(new DateTimeType(dt.toInstant())) ``` Previous result with system time-zone CET/DST: ``` [openhab.event.ItemStateChangedEvent ] - Item 'DateTimeTest1' changed from NULL to 2024-04-26T00:00:00.000+0200 [openhab.event.ItemStateChangedEvent ] - Item 'DateTimeTest2' changed from NULL to 2024-04-25T22:00:00.000+0000 ``` New result with same system time-zone: ``` [openhab.event.ItemStateChangedEvent ] - Item 'DateTimeTest1' changed from NULL to 2024-04-26T00:00:00.000+0200 [openhab.event.ItemStateChangedEvent ] - Item 'DateTimeTest2' changed from NULL to 2024-04-26T00:00:00.000+0200 [openhab.event.ItemStateChangedEvent ] - Item 'DateTimeTest3' changed from NULL to 2024-04-26T00:00:00.000+0200 ``` Summary of benefits for developers: - In cases where `TimeZoneProvider` is used only to generate a `DateTimeType` with the correct time-zone, this can now be completely removed. This simplifies the code. See openhab/openhab-addons#17725 for examples. - The default `DateTimeType` constructor can now be used (without losing correct time-zone). - In cases where the configured time-zone was not correctly applied, this will now work properly without any changes. - The change is fully backwards compatible, although two methods have been deprecated: `toZone` and `toLocaleZone`. I will go through usages and remove them, since they no longer make sense. See openhab/openhab-addons#17725. - Pull request reviews should be a bit smoother, since add-on maintainers will no longer have to assist contributors in constructing a proper `DateTimeType` using `TimeZoneProvider`. And for users: - There will now be consistent behavior across all bindings, where previously time-zone could differ between bindings and even within same binding: System time-zone or openHAB time-zone. - There will now be consistent behavior across different parts of the UI, where previously some parts used the time-zone contained in the `DateTimeType` (which could be either depending on binding) and other parts used system time-zone. - A change in time-zone will have immediate effect for the UI without requiring state updates for the items. And finally limitations: - It is no longer possible to send a `DateTimeType` command to a binding with a specified time-zone. The bindings will have to provide a time-zone if needed (e.g. time-zone from device, openHAB configuration or system time-zone). I have not found any bindings using this possibility, so I don't think this will cause any issues. Resolves #2898