RIght, but that’s a timestamp sensor, and it’s not an attribute. Attributes can contain objects. Information passed to and from node red/ home assistant will be JSON. JSON cannot understand objects. It understands basic types. I.e. strings, booleans, integers, floats/doubles, lists, and dictionaries. A datetime object will be converted from a datetime object to a string automatically by both systems, node red and home assistant.
Node red’s backend is all JS, so when it converts the JS date object to a string, it uses whatever built in method it has to convert the date to a string. This is not an iso formatted conversion. I believe this is done through the .stringify method on date objects in JS but I’m not versed in JS without googling how to do things.
Python has the exact same building blocks. It’s also not a iso formatted conversion. This is all handled through the .__str__ method built on objects. The output of a python datetime objects __str__ method changes based on the contents of the datetime object. I.e. it will omit microseconds if they are zero, etc.
you misunderstood me ive worked for more than 15 years, are use to “formatted” timestamps in logs, requests etc. etc. … in a GUI, normal practice to render this, i dont want my clock in top corner showing ISOformat with T+ timezone, and not if want to see, or use “attributes” ( AS is) … if i “need” it in a particular format other than mainstream front-end, i believe im already “addressing” a template, and if i (as in your case) copy date-time from front-end, or in case direct from sensor, but “delivered/pulled” as not-timestamp-string
But when data goes through API objects are serialized the same way, regardless it’s payload or attribute. Sensor payload retrieved from API is just a string. The same string as in attributes. It must be language agnostic (and it is). So it’s not object anymore (in a meaning of particular programing language).
TBH I not getting it.
If HA programmers are able to convert datetime object to ISO string in order to pass it as payload, the same method may be used to create attribute.
I assume the difference is that:
in case of sensor, the payload is created at very end of pipeline, likely by API, where API is responsible to convert datetime object to ISO representation and put the result to message payload
in case of attributes, since those are still just strings, and API ‘don’t know’ the intention of programmer, it is responsibility of object creator (integration) to fill attributes formatted in needed way. This is what I’m doing when I’m the author of attributes, making them to be compatible with other routines
Recently, a bug report of mine got closed without warning. When I inspected the bug report history, I noted that a bot marked it as “stale” about a week prior to the same bot closing it.
I got notified about the closure of the issue, but not about the marking of the issue as “stale”. Historically, this action was accompanied by a courtesy message like “comment on this issue if it’s still relevant and we’ll keep it open”. Has this courtesy notification dropped out in error?
Exactly what I noticed too, but had no time to prove that.
Now I checked email history and I can confirm I got no this notification too.
And the time needed to stale and close has been decreased significantly too.
To me all those things together (it cannot be made by mistake) looks like intentional actions making reporters unaware in order to close as many issues as possible without even checking them.
