Jacob Laursen

> From my side it _is_ ready though (that is, I do not have any additional improvement ideas at this point). The open thread should block it from being merged...

> Won't either ultimately drive reviewers away from reviewing this? `The author isn't done yet, so it's pointless to review at this point.`? Potentially yes, but with some sense, since...

> > since from a priority perspective, time is better spent reviewing PR's that can actually be merged soon. > > Just a remark regarding that prioritization from the perspective...

> Draft status will effectively prevent the merge button from being accessible, while a lot of text conversations can be harder to interpret and ultimately could lead to a wrong...

@maniac103 - there are some checkstyle warnings left. You could take a look at target/code-analysis/report.html.

And today https://github.com/openhab/openhab-addons/actions/runs/6492582809/job/17631797376: ``` TEST org.openhab.binding.wemo.internal.handler.test.WemoHandlerOSGiTest#assertThatThingHandlesREFRESHCommandCorrectly()

@seime - would you like to pursue this PR to have a solution until core will be enhanced in this regard?

@kaikreuzer - browsing through some old PR's I found this one. 🙂 With your latest comment, does it mean this PR is actually in a condition where it could be...

@J-N-K - what would be the correct way of making `TimeZoneProvider` available to `DateTimeType`? That would probably be the first step to provide compatibility. Then it could be be refactored...

@J-N-K, @fwolter - thinking about this again, does `DateTimeType` strictly have to use `TimeZoneProvider`? This seems like a "convenience conversion" if we would actually like to move time-zone out of...