device:emit_event(caps.dishwasherOperatingState.completionTime("2022-09-05T14:18:45Z"))
this piece of code generates 4:18 PM… funny, but it’s wrong TZ and don’t know how to change it
device:emit_event(caps.dishwasherOperatingState.completionTime("2022-09-05T14:18:45Z"))
this piece of code generates 4:18 PM… funny, but it’s wrong TZ and don’t know how to change it
I agree with you @ygerlovin, time needs to come from location, as that’s were automations are executing.
Paul this would be very useful. We have a few drivers in the works that schedule activities on a recurring basis but these will only work if there’s a local timezone (locks, thermostats, cameras are the immediate ones). The easiest way would be to set/update the timezone offset as part of the driver structure when the geolocation is set (like groovy used to). If there’s no geolocation the offset can be set to null (to differentiate from GMT). While this is the easiest way to start, at the outset, I would recommend adding one of two options for handling daylight savings time.
Thanks for the feedback, @RBoy.
We already created a feature request for this. Just as a heads-up, it can take some time to be reviewed and implemented.
+1 for this feature as well. I want to use it for circadian lighting algorithms. In my case, I even have the Olson ID for the timezone which comes from the device. I really just need the timezone tables to lookup the offsets. I may embed them, but that is a lot of bloat for drivers that will use up memory. Having those tz tables onboard would be preferable.
@posborne I would suggest the team look at lua tz as it may be a useful start for a platform library. GitHub - daurnimator/luatz: Time, Date and Timezone library for lua