[New Cap] Timezone control

[depau]

Starting the discussion here first to properly follow the new process.

JS

• class TimezoneControlCapability
  • getTimezone() -> number (offset to UTC)
  • setTimezone(number)

REST

• GET / -> timezone offset as a valid JSON number
• PUT / body {"action": "set", "timezone": number}

Using offsets and not human readable time zone strings such as Europe/London to keep the code simple. Though conversion back and forth should be just a matter of including a mapping somewhere in the code, if desired.

Thoughts?

[Hypfer]

My plan was to not have any timezone control and instead use UTC on the robot + design all APIs to expect and return timestamps as UTC.

The front-end can then do timezone conversion based on the user locale.
Apart from making things easier in the backend, the user also benefits from less confusion caused by indirection due to their computers timezone being the reference for everything that they're seeing

[depau]

That works too, I'm not a front-end person so I can't really make any consideration about that.

However what I can say, though, as a system administrator, is that having the system timezone different than that of the main users or administrators of the machine is quite annoying when working with the system.

What I can say as a back-end developer is that since this is not a publicly used, world-wide accessed service, but rather a service that runs and manages a device that works in a very specific timezone, a device that may wake up neighbors in one specific timezone regardless of where in the world the person controlling it is located, having the timezone follow the controlling user can be quite annoying.

Think of this example: my vacuum is in Milan and I'm on a trip to New York, I'm connected remotely to the vacuum to adjust the schedule and do not disturb settings while I'm away. Which timezone matters? In my opinion Milan, since that's where people are going to get annoyed if I do the math wrong.

While I do agree that your approach is the best one for a generic web application, such as a blog or forum, for this particular application I think Valetudo should follow the vacuum timezone and always display times relative to that, not to the browser's. Also considering that Valetudo does not have persistence, I don't see what complexity would be added to the back-end.

In any case, if you prefer the UTC approach, we have to make changes to the do not disturb and scheduling capabilities, since (at least for viomi) they currently use the timezone of the device and not UTC. On top of that, the UI-displayed timezone can't currently be adjusted.

Let me know if I should go on with this or make sure Viomi is set to UTC.

[Hypfer]

having the system timezone different than that of the main users or administrators of the machine is quite annoying when working with the system.

I can relate to that, however for me that's mainly an issue experienced when working with multiple machines/services of which some are UTC, some are Localtime and some are Localtime but in a different timezone. Therefore, having UTC everywhere solves that.
Granted, it's also easier to say that while living in Germany since Europe/Berlin is UTC+1/UTC+2 and that's easy to work with.
Something like UTC - 8 probably gets harder to understand/work with rather quickly.

I also definitely see your point regarding that a device is in a specific location and therefore it makes sense that everything time-related should be in it's local timezone. On the other hand, the use-case "I'm abroad and I want to change my vacuums schedule" to me seems like something that won't happen very often.

Something that will instead happen often is a user picking up a device that is right in front of them and just wanting to set up DND/Schedules/Time-based things.
In that use-case, having to set up the robots' timezone before being able to do anything is basically a chore that is required for technical reasons, except that it actually IMO isn't strictly required.

Considering that a scheduling feature inside Valetudo would mostly exist for the less technically skilled without a full home-automation setup, I'd argue that optimizing for that group would be the right choice here. They definitely won't have any remote access configured anyways

In any case, if you prefer the UTC approach, we have to make changes to the do not disturb and scheduling capabilities

Thanks for pointing that out! I completely forgot about the DND capability

[Hypfer]

Another thing to add would be that it's easy to convert js dates between localtime and UTC but incredibly hard to do the same conversion between multiple timezones.

Granted, that's a restriction of the programming language and can be overcome by using a library, however I'd like to avoid those if possible and of course technical limitations aren't the main point here.

[depau]

Another thing to add would be that it's easy to convert js dates between localtime and UTC but incredibly hard to do the same conversion between multiple timezones.

Javascript is weird :)

Alright, then I think I will have to ensure Viomi is using UTC during the robot initialization/first connection.