-
-
Notifications
You must be signed in to change notification settings - Fork 420
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DateTimeType] ZonedDateTime, Instant or neither? #2898
Comments
@doandzhi are you still around? Can you remember why you stripped the DST information when refactoring Some unstructured thoughts to start a discussion: I can't think of any use case for which it would be necessary to store the time zone information of the source of the When a binding creates a Modern browsers can provide the client's time zone upon request. I would expect date & time displayed in the MainUI to be in the client's local time by default. The offset of the displayed date & time should be independent from any time zone setting when the The system time zone shouldn't play any role on this entire handling, since there might be use cases where you cannot configure the system time zone as @wborn pointed out (e.g. OH running in cloud). I think the majority of user interactions with There must not be any breaking change to the interface of |
IMO the implementation should be changed to |
@J-N-K - what would be the correct way of making |
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/openhab-4-0-wishlist/142388/106 |
Difficult. I have no good idea yet. |
@J-N-K, @fwolter - thinking about this again, does If we would refactor all usages into using For backwards compatibility we could still use Maybe I'm just trying to avoid facing the fact that I have no clue how to inject a provider into a type. In any case, as preparation, I believe some usages of Btw, the default constructor currently uses the system default time-zone (through WDYT? @ghys - perhaps you can give some advise how/where to approach this in Main UI, and/or if it would be viable to switch to browser time-zone here? |
I agree that this can be seen as a convenience method. I'd further say that the use case of a timezone conversion in rules is pretty small as most OH installations are probably located in a single time zone. (Time zone conversion e.g. in MainUI could be done in the UI and time zone conversions from a physical device should be done in the binding, IMHO)
Do you mean for backward compatibility? I think the source time zone is quite irrelevant, once converted to
I think this would be a good compromise. It doesn't feel good to introduce a dependency to There's another use case having EDIT: A compromise would be to have a "convenience" constructor like |
Yes, I meant for backwards compatibility. Currently contributors are encouraged to use For a conforming binding this means the correct time-zone can be assumed in rules. If we would strip time-zone from provided
Agreed.
I agree with this compromise as otherwise the type would still be entangled with the provider, leading us back to the injection problem. |
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/dishwasher-price-calculation-automation/139207/10 |
I'm creating this issue in order to discuss how DateTimeType should work. It seems like currently it internally stores a ZonedDateTime stripped of ZoneId, but preserving a ZoneOffset:
openhab-core/bundles/org.openhab.core/src/main/java/org/openhab/core/library/types/DateTimeType.java
Lines 75 to 77 in cabb3f7
This means that information about Daylight Savings Time is lost. Expressed as DSL rule:
Result:
(side note: I have [Europe/Copenhagen] configured in openHAB, so DSL rule engine doesn't seem to use TimeZoneProvider for
now
)This has been a problem for at least openhab/openhab-addons#12546.
I'm wondering if
ZoneId
being stripped is a feature or a bug? It seems intended aswithFixedOffsetZone()
is explicitly called, I'm just not sure why.Instant?
Second, a bigger topic: I'm wondering if it even makes sense to store a
ZonedDateTime
forDateTimeType
. It's documented here:https://www.openhab.org/docs/concepts/items.html#datetimetype
When constructing a
DateTimeType
for a channel, we need an unambiguous timestamp which could be expressed as an Instant. Any logic that would need time-zone information could obtain this from another source, namely TimeZoneProvider. This of course must be possible anywhere needed, including within rules running in a scripting engine. The advantage would be that the logic is applied for the currently configured time-zone.Currently when
DateTimeType
is displayed in any UI without any custom formatting for the channel or item, the rawZonedDateTime
string is displayed, for example: "2022-04-06T22:11:29.183905+02:00". In my opinion, this should be converted to local time. It is also worth noting that this string currently depends on the time-zone from the system or openHAB at the moment when theDateTimeType
was created, not according to the currently configured time-zone. When using a pattern like "%1$tY-%1$tm-%1$td %1$tH:%1$tM:%1$tS" to convert to local time, it doesn't really matter which time-zone the system was in. All we need is anInstant
and currentZoneId
so we can display it in the local time-zone currently configured. And in fact when using mentioned pattern, the two DateTimes 2022-02-28T21:24:52.000+0000 and 2022-02-28T22:24:52.000+0100 are both displayed as 2022-02-28 22:24:52 for my time-zone.The text was updated successfully, but these errors were encountered: