I am a European living in the USA so I often get confused on dates… is 06-03-2024 the 6th of March or the 3rd of June? For that reason I either use YYYY-MM-DD or DD-MMM-YYYY. The latter is shown below and is achieved with a template. The format in the huge (please make it smaller!) date picker is based on my system settings and follows my preferred order of DD-MM-YYYY… however now there are two formats on the same dashboard and non European users will still be confused.
Summary - please add ability to format the date display to the input_datetime control.
An example of what it could look like:
- entity: input_datetime.air_filter_replaced_garage_entry
name: Replaced on
format: 'dd-mmm-yyyy'
An alternative could be to have a system wide setting to enable displaying dates in the user’s chosen format. However, please don’t tie this all to the locale setting as it is really annoying when you live in a country that doesn’t use your preferred standards. If I recall correctly, in order to have the dates shown the European way (or maybe to get the 24h clock), I had to change language to English (GB). While I see the logic, it is quite inflexible and annoying as it forces the user to pick between spelling of words or date and/or time formats. There is no one size fits all.
I don’t get it, sorry. There are settings for exactly what you want in the user profile. You can choose the timezone, the format, the language, whatever you want. The default is set to “system settings”, but you can always override them. And what I just tried, I can mix and match as I want on a user basis, so in your household everyone could use a different format.
And if you need that changed, you were already heading in the right direction: change the display in the frontend or with a template sensor. There are filters you can use for a custom format, if necessary.
Please let me know, if I totally misunderstood your point, but try the user settings first.
Unfortunately I see no option for an abbreviated letter representation of the month such as in dd-mmm-yyyy (ie 20-Apr-2024), or even an option to swap the separator / with - or ..
I am not sure if the list below is complete, but even if partial, the current configuration options in HA only appear to allow a limited subset - variants 1, 2 or 3 in my case.
MM/DD/YYYY (e.g., 04/20/2024)
DD/MM/YYYY (e.g., 20/04/2024)
YYYY/MM/DD (e.g., 2024/04/20)
MM-DD-YYYY (e.g., 04-20-2024)
DD-MM-YYYY (e.g., 20-04-2024)
YYYY-MM-DD (e.g., 2024-04-20)
MMM DD, YYYY (e.g., Apr 20, 2024)
DD MMM, YYYY (e.g., 20 Apr, 2024)
MMM. DD, YYYY (e.g., Apr. 20, 2024)
DD. MMM. YYYY (e.g., 20. Apr. 2024)
There may be the option to configure HA to use other variants by also changing the language… but that can be a deal breaker. For example, I grew up in Italy and always set all my electronics, PCs, etc. to English as the Italian words and/or translations were terrible, too long, or just made the UI unusable due to the abbreviations or incorrect translations. For this reason Italy tends to adopt English words for all tech stuff.
An alternative option to adding date configuration options to the input_datetime entity for display purposes would be to expand the user level date configuration options and to enable templates to use the user’s preferred format (maybe already the case) so that the two match. This latter option is the best technical solution but may be much more complicated to do and might have significant implications. My original proposed solution should be easier to implement and harmless given it is limited to display purposes typically within the same family.
There were some feature request in the past, that went into the same direction, but stopped short of implementing a custom format for the date.
This feature request was implemented already, so it would be a new one with the request for a custom date:
You didn’t specify for how many different users you need the date. My first idea would be, to setup one template sensor per user with the wanted format, if possible for that number of users.
And when you need the date, use a conditional-card to show only the card specific for that user.
That might not fit all occurences, but at least for a few, hopefully. And for a setting, we’ll see how a feature request works out…
@paddy0174 - I edited the post you replied to extensively but posted after your reply - sorry. You might want to glance at it again.
I am glad the other FR was implemented as I was/am in the same boat. In my previous post I briefly touched on an alternative but it may be a taller ask. Quoting myself from the updated revision of my post above:
Why so complicated? The system internally works with a unix timestamp, so what you make of that, is something a simple user setting could achieve. Everywhere where the timestamp is already changed to the choosen format, why not use a custom format here?
I honestly have no idea where and how this is handled in the code, but I can’t imagine that would be a big change. It might be tedious to change all occurences, but these aren’t really programming changes, it’s more like a typo.
I’ll have to lookup how many occurences are there, just out of curiosity.
