laursen
December 9, 2024, 5:59pm
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:
openhab:main ← jlaur:2898-datetimetype-instant
opened 10:09PM - 29 Apr 23 UTC
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
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:
I think deprecation has both advantages and disadvantages.
3 Likes
