Need a name for sensor device class to show relative time about architecture

[balloob]

I think just making it device class timestamp is the way to go . If timestamp is in the future, we add "in X", else it's "X ago", depending on locale.

With experimental UI, people can choose if they want to see the relative time or the timestamp.

[OttoWinter]

I mean it might be appear as a period in the frontend, but in the back end it's just a timestamp, right?

If we were to call it "time period" I'm sure that could cause some confusion when someone tries to use this device class to show a static time period, like travel time to work.

So I would say "timestamp" would be more appropriate.

[c727]

Hmmm... Uptime: 3 hours ago is a bit strange. So I will also change the default name to something like Restarted or we create 2 new classes: one will show 3 hours and the other will show 3 hours ago

[OttoWinter]

Ok so I think there are three types of times that could be represented by sensors:

• "Static" time period, like the amount of time to get to work. 15 min. Suggestion: time_period (TBD)
• A timestamp; an event at a specific time. As per @c727: 3 hours ago. Suggestion: timestamp (TBD)
• Combination of the two. A time period that starts from a static timestamp like uptime. Suggestion: relative_timestamp (this issue)

Obviously, it won't be possible to accommodate all of these in a single device class and we don't need the other device classes yet, but naming these consistently from the start is definitely good 👍

[balloob]

I guess if we keep device classes to the content, timestamp is in this case the most appropriate. I guess the frontend will need to be updated to render it then both by showing the timestamp and showing how long it was ago. Depending on the data, one could be more important than the other.

[c727]

And do you think we should support both: uptime: 3 hours and restart: 3 hours _ago_ or is one enough?

[c727]

Otto, I think for the static example we don't need a class as the state would not be updated every interval

[exxamalte]

Displaying a timestamp as a relative time from now is very use-case dependent, so keeping data type and view type independent would be preferable.
Also, keep in mind that the timestamp can be in the future: "Next Bus: in 5 minutes"

[c727]

^it will only effect this one device_class

[awarecan]

I also need one to display timestamp in future. For example, ETA: in 5 minutes

Ha, just saw @exxamalte comment after submit my comment.

[balloob]

Okay, we're going for timestamp. UI support is landing in 0.84 for it: home-assistant/frontend#2087

UI will support all the different display options so we don't have to make a choice

[balloob]

Dev docs PR: home-assistant/developers.home-assistant#147