Dashboard Tiles Format Incorrect

C-7 v2.3.6.146

From my rule:


Date is added on Dashboard tiles:


From Settings-Hub Details:


Why is the date added and time format changed?

You can set the clock 12 hour time or 24 hours time in the dashboard setting.
As for the date. What device are you using and maybe an attribute just for the time is available to use in the tile template selection.

Dashboard is already in 12 Hour Mode:


The Dashboard tiles are populated by DateTime Hub Variables:


Looks like the Hub Variable is modifying the value once it's set?


@bravenel Can you confirm if this is expected behavior or a bug?

i.e. if a Hub Variable is set to a time 7:25 AM, should the date be automatically added?

I'm not sure what you are referring to above. DateTime variables have both a time value and a date value, either of which can be omitted when the variable is created or set. If both are present, then they will both be displayed, depending on the context,

If you don't want the date portion, you can erase it. Setting the time won't clear the date, if it's already there:

I cleared the date from each variable:

Then ran these Actions:


and the date was set on the variables:


It appears the date is added when setting the time on the Hub variable.

That's because sunrise time is dated. That time only applies to that date.

Why then are the values displayed without the date in the Rule?


Yeah, some of that is UI treatment. Ideally, the Dashboard should allow more control over presentation. I'm thinking as a work-around an action that clears the date from a DateTime Variable.

Like this:

Next release...

1 Like

I considered the possibility of adding an Omit Date toggle to the actions that set a DateTime variable. I'm not sure whether to do that or not. This approach was much simpler to implement, just 2 lines of code, but does result in one more action in a rule. Thoughts??

Sorry to but in, but would it be easier / better to have a setting on the variable for whether it records a date, time or date and time? That way it does not rely on the action configuration?

No, this would be a huge mess. The way DateTime variables work is fairly intimate to how dates and times work in the underlying system. This would be tantamount to creating more types of variables, adding a lot of complexity in lots of places.

Ok, that's fair enough. I certainly wouldn't want to see a big amount of work to fix an issue like this.