Settings - Time

[flatsiedatsie]

It seems the gateway currently supplies the wrong time (if I understand correctly).

There is no option in the UX for setting the time / clock.

I don't know if setting a location / timezone would be a better / enough of a solution.

The issue of Europe stepping away from summer/wintertime is also coming in the median future.

See also:
#1113
#1428

[tsathishkumar]

@flatsiedatsie , I think gateway is not the right owner for this issue. The controller(MySController-rs) is the one currently responds to time request from sensors.

[hobinjk]

I believe #1113 is the best way of solving the time problem but I agree that there are benefits to being able to manually adjust the gateway's time

[flatsiedatsie]

@hobinjk I thought about is some more, and setting the time would definitely be important because in my opinion it should be possible to use the gateway without any internet connection. For the product I'm developing around the Mozilla Gateway this will be the default mode.

[edwoody]

there's a display of date/time when keying in "date" in the pi. Just not in the gateway software. Mine is about 6 min slow. A way to view time or set time would be nice.

[flatsiedatsie]

I'm running into this again as well.

The MySensors adapter uses a library that has a built in feature to tell the nodes in the network the time. it simply sends the Unix time from the Pi to the nodes. I use this, for example, for an alarm clock. It requests the time from the controller.

As the Pi is on UTC, this means my alarm clock displays a time that is two hours behind the actual time.

I could try to hack/modify the library to override it with a shifted time somehow. But even then this would require the WebThings Gateway to tell the adapter what the user's actual timezone/time difference is.

[tim-hellhake]

As the Pi is on UTC

Unix time is per definition UTC.
Showing the correct local time is a matter of localization and should be done by the ui/display itself.

the user's actual timezone/time

But which user? As I understand it an addon is installed per system not per user.

[flatsiedatsie]

@tim-hellhake You're right, I meant to say a timestamp in Unix format.

"As I understand it an addon is installed per system not per user."

Great! A system has a physical location, and that is always in a timezone. Setting a system time is a great place to start.

[dhylands]

There are probably a number of ways to deal with this.

One way is to run raspi-config and set the timezone. Then when you ask for the localtime it will give you the proper local time.

We should probably make setting the timezone part of the first-time setup.

[flatsiedatsie]

"One way is to run raspi-config and set the timezone."

The problem is that, at least currently, the logs don't work properly anymore if the system is not on UTC.

// Here's a link to the issue.

[tim-hellhake]

The problem is that the logs don't work properly anymore if the system is not on UTC.

Then maybe we should fix that ;-)

[flatsiedatsie]

I really ran into this issue while creating the Voco add-on. One of it's features is that it allows users to say things like "set an alarm for 8 o'clock".

Currently the add-on has to deal with 3 different times:

• The local time according to Raspbian. In my test case, this was set to London time (+1) out of the box.
• UTC standard time. This can be derived from the above, and is used internally for time delta calculations.
• The time zone that the user is actually in. Currently, the user has to set this in the add-ons settings. E.g. in Paris the difference to UTC is +2 hours, or 7200 seconds.

It's.. a lot of operations, which could be avoided if the WebThings Gateway could be relied on to have the actual local time of the user.

More importantly, it's fragile. The problem is that when the user says "set an alarm for 8 o'clock", Snips will internally deduce when the next 8 o' clock is based on the internal clock.

This leads to weird situation. E.g. imagine that the user's is in Paris at 20:15 and they say "set an alarm for 8 o'clock". For them 20h has passed, and the next 8 o'clock will be in the morning. But Snips, which is operating in London time, will return "20h" as the desired time, since according to it the next "8 o'clock" is just 45 minutes away.

There are a few solutions:

• The user could SSH into the device and set the time and locale using raspi_config. That goes completely against the wonderful usability of the rest of the gateway.
• The add-on could force a new timezone for the entire device. (I haven't looked into if this is actually possible). But then you get the issue of multiple add-ons all overriding each other all repeating this code.

Ideally, a user sets their local time/zone in the Gateway UI.

[flatsiedatsie]

As far as I can tell from the new code, it allows a user to set the time zone, but not the actual time? So the system is still dependent on a third party service for that? Which means the system is still regularly "phoning home" to some unknown party?

[mrstegeman]

It is only "phoning home" in the sense that it is pulling the current time periodically via NTP from the NTP pool. NTP request packets don't have anything sensitive in them.

Our reasoning for still using NTP versus having the user manually set the clock is discussed here. However, the user can still use the gateway completely offline, which means NTP wouldn't be used. In that case, they'd have to handle the clock on their own.

[createcandle]

NTP request packets don't have anything sensitive in them.

They do. Your IP address is considered personal data.

On top of that, privacy invasion isn't just about the content of the packet. It's just as much about observing behavioural patterns.

Nothing is free. Is Mozilla paying the NTP server pool? Do you have a subscription to it? If not, it means they are making money some other way. From what I can tell, anyone can add their server to the NTP pool, meaning you can't be sure who is getting the ping from your system. It might be Facebook, Google, etc.

On top of that, any intermediary server along the route could find out that this IP address requested the time. A whole string of servers is informed that my IP address is connected to the internet, and that I just booted up a system. "this household has a lot of servers / reboots them a lot" -> insert derived or inferred algorithmic conclusion here.

In the data economy, any signal is useful. If there is data, it will be fed into algorithms that derive and infer new data from it. The best way to protect privacy and enhance security is to not emanate any signal in the first place.

Our reasoning for still using NTP versus having the user manually set the clock

That's a false choice. You could support both?

Ive already been in situations where if would have been very useful to have an option like "click here to synchronise the clock with the browser time". Users may be off grid when a reboot happens. Imagine the gateway being used on boats, trucks, camping in the wilderness, etc. Trade exhibits where you have to pay extra for an internet connection, etc.

It cost $300 at Dutch Design Week, for example, which we didn't want to pay to show off a system that we were presenting as being able to work without an internet connection. But this meant that every morning (exhibits must be powered off at night) someone with SSH knowledge had to be at the exhibit to log in and set the correct time. Visitors could then ask "hey Snips, what time is it" without getting an incorrect value. If there has been a UI for this, people with less technological skills could have taken care of this issue.

https://resources.infosecinstitute.com/network-time-protocol-ntp-threats-countermeasures/