yes i follow that , i just looked a some of my “timestamp-sensors”(and result) and others, might be that, google-calender-sensor might not have the “original_device_class”: “timestamp”, … so the T get lost in “translation” … rendered as the “front-end” … i dunno
Could you look that up in " .storage\core.entity_registry "
edit: ahh just realized that google_calendar is cloud_polling … might change the “ballgame” … good night to you
edit: … and it absolutely not looks like the " 1 sensor" provided is a “timestamp” sensor, so another question arise, does google calendar API ( when signing-up @ google_calendar) provide a “timestamp” sensor ? " [Google Developers Console]
edit4-or5: if “provided” as a string (in sensor), i guess you have to wait until AI can solve this
Not sure. But the the original issue refers to value stored in sensor attribute while class defines sensor value (payload). In other words it’s nt related to class at all. But to strategy of HA moving toward standardized time format
ok, thou i still have hard to imagine, how HA should decide a “no timestamp defined string” provided from an external source, should be considered as a “Timestamp”, but again i have no clue what i “pulled” from Google, and no clue how the ha_core_google is implemented … and i rest my “case” i dont intend to read the source for that … edit: and if i found some devices, showing “Timestamp” ( Date-T-time) in “attribute”, it would annoy me( thou i guess they could “render” this from “input”)
Google calendar is a tool allowing cooperation between people over the globe. It has to work with fully qualified timestamp otherwise it wouldn’t work.
So I assume calendar data provided by google api has proper representation allowing to build fully timestamp (and it does)
My guess is, google calendar component intentionally converts those timestamps to local time and storing in human readable form (without T) which was valid/working approach in the past, when HA infrastructure wasn’t ready for coping with timezones.
Now I can expect all timestamps will be successfully converted to fully qualified form. Making timestamp sensor being comply with that is just the first step
Regarding the format itself it’s just a way how to represent particular data in strictly defined way. Nobody should be annoyed by the ‘T’. It can be transformed during representation phase (on FrontEnd) into more ‘clean’ form or transformed to whatever timezone then. But it’s FE’s responsibility. So if annoys anyone, it the improvement should be requested against FE component.
But we are drifting off the main subject. In fact reported issue was intended to help devs to fix places which are dependent on recent strategy regarding timestamp. After it’s automatically closed, they lost value potentially provided by this issue.
WUSIWUG … guessing and assuming, and with that as a base, accusing DEV, complaining over a “closed” issue, which you btw, have solved your self ( aint a good way to) … and i still don’t get ( do you really mean you want to “SEE” 2022:2:27T12:21:21 in attributes ( I DIFFINATELY DONT ), or you just want use this elsewhere, ( btw is what are these “timestamps” for) … yes we are drifting, you have “changed” the subject a few times, and you have discovered during this “trip” that there is alot you don’t know, but you really sounds like you have long time experience/knowledge with HA sensor communication, programming etc( way more/longer than me)., and it haven’t crossed you mind to, instead of spending time reporting an issue, you really don’t know where belong, and i mean beside the time you spend solving it your self, and time here in this “Topic”, that you could have spend, checking your sensors, the source-code, dokumentation etc. The “Topic” btw was a “delusive” “Headline” , starting with (2 lines, Do you really think/Do you really know, etc. etc.), ok i got that this bad “awful” auto-bot closed your reported issue, you don’t know why, you don’t even know if your reported issue was written in a way to really understand what’s wrong/if anything, or if it’s a feature request" and it doesn’t seems to me, that you know what’s in the source-code, what information does google provide, and in which format … if you had this as a fact, it should have been in the “bug” report… other-vice auto-bot will just get tired and try to strengthen it’s capabilities, to ditch … ( and i really don’t know how many of those hardly 5% using google-calendar, who wants/need the info in “attributes” hopefully not showing in format 2022:2:27T12:21:21 … you got with a “space”(i asume), many things was “unclear” in your bug-report, and you have the knowledge to fix it( and have) to your needs … now don’t forget to enjoy your weekend
A bug report is a bug report. Role of a reporter is to report an issue (in this case incompatibility between 2 core components). Not to find root cause of the issue. This has to be done by developers.
do you really mean you want to “SEE” 2022:2:27T12:21:21 in attributes ( I DIFFINATELY DONT )
In this exact example you are missing time zone. But yes, using ISO formatted timestamp incl. timezone is the way to make this notation consistent across whole system (not speaking about potential consequences of lack of this information).
The fact you don’t like it (probably because you prefer displaying those values without further processing) is not argument here. As I said, ISO format is a standard, and seems it has been decided by HA team recently to migrate toward it. So sooner or later all time information will be stored and provided through APIs in this format.
Personally ISO format and timezones isn’t anything new for me. I work with that on daily basis. It’s inevitable like UTF formats (It remind me transition from 8-bit charsets to multi-byte charsets, incl utf8, and how people was reluctant to step into that)
But again, this thread is not about resolving my issue with timestamp (I did it on my own months ago). It’s about closing issues without reviewing by developer. So wasting the work of reporter and loosing potential value of the report (if found by developer). If the settings are not by mistake, and HA team is OK with all consequences of loosing potentially valuable information, then there is nothing to discus left.
I just want to be clear here, the current acceptable values are a iso formatted timestamp or python Datetime objects. Which when stringified are not iso formatted. So there will still need to be changes in node red for your use case.
EDIT: As it stands, I’m pretty sure this is what’s happening anyways right now. All the code points to those attributes being datetime objects, but for you they are strings. I believe on restart, those may be getting stringified and that’s what you’re seeing. Otherwise it makes no sense that they aren’t datetimes.
Not excactly true. Or I missed something in your note.
When reading timestamp sensor in NR, it returns ISO formatted timestamp. Writing the value to this sensor using NR also requires ISO formatted string, incl TZ., otherwise it’s rejected by HA API.
Edit: requirement of TZ is something new, added between 2021.10 and 2021.12. In 2021.9 it wasn’t required. ‘T’ is required for long time (at least more than year)
So, one could assume that sharing time data between NR and HA requires ISO incl TZ
It doesn’t apply to mentioned attributes (of google calendar sensors). Which leads me to impression, that while timestamp sensor is built from the timestamp object, attributes are still just strings, anything programmer put there. So those are not a subject of datatype validation.
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.
… good night to you 
