Add relative timestamp state_content for input_datetime

[MrEbbinghaus]

Proposed change

Currently the timestamp attribute of input_datetime entities is displayed as a simple number:

While sensors with device_class: timestamp display a relative time string:

This PR adds a relative timestamp to the state_content selector of the input_datetime entity:

Note that it doesn't replace the timestamp, it just adds another option. A freely configurable "format selector" per datatype would be better, but that would mean bigger changes. (see #20618)

I implemented this by adding a map that allows an attribute to add multiple additional options to the option list.

While I was at it, I removed the digit grouping of the timestamp and year attributes, as they didn't make sense. I thought about using the hour, minute, second, day, month, year to render a single nicely formatted option, but that would be beyond the scope of this PR.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (thank you!)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example configuration

type: tile
entity: input_datetime.bjorn_nachster_wecker
name: Wecker
state_content:
  - timestamp_relative
  - timestamp
  - year

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

[wendevlin]

Hi @MrEbbinghaus,

Your timestamp_relative label won't get ever translated, because this labels uses core translations and there it's not defined

[piitaya]

Thank for the contribution. I'm not sure we should add another option. I would prefer to format the timestamp correctly instead of using option. I'm also in favor of adding a format option to every card to let the user choose between relative or absolute.

[MrEbbinghaus]

@piitaya I agree that this change is kind of tacked on and a general formatting system would be better.

In principle, it feels bad, to change the representation of an attribute so dramatically. In this case, however, I guess it would be fine, as I don't think that there are currently any users who would prefer the raw number format.

(Who came up with the idea that a timestamp should be represented as a relative time anyway..?)

---

Speaking of formatting, I think some general templating support would be great. This would allow users to format values however they like.

For known predefined attributes, the UI could still provide a selector that just sets a template internally. This could simplify the definition of format development, as you would just have to map (domain, attribute, format) => template. (Which could even be easily extended/modified by user configuration, since it is just data.)

Considering your work on lovelace-mushroom I think this is not a new idea. 🙂

---

@piitaya I guess it is up to you to decide. Either:

• I update this PR to just change the formatting of timestamp.
• Or we drop this change entirely in favour of a future formatting overhaul and we just cherrypick 088097f.