I agree closed issues too soon is frustrating.
Have you considered fixing the issue yourself and send pull request ?
Hard to call it consideration. not that this thought didn’t cross my mind. But I have a lot of other activities which limit me to be a reporter only (which is also under big question-mark after seeing how easily my work is being thrown to the trash)
Anyway regardless my answer, it doesn’t change the fact that current policy is hard to understand. The only valid argument I think of is creating an impression that HA has very low number of issues. Which would be BS then of course.
Between 300 and 450 issues are created each week. Between 600 and 1000 PRs are merged each month. The average month has 5 weeks, that’s 1500 issues to 600 fixes. The bot is in place to keep relevant issues in the queue while filtering out issues that are not issues (more support). The bot ends up cleaning those types of issues automatically because users find the error in their setup and fix it. This puts the control in the users hands to keep issues alive if the issue is in fact an issue. It’s not a perfect system, but it’s one of the only ways to keep the issue list manageable with the resources we have available. This system works very well when integrations have code-owners. Unfortunately, the issue in question was written against a code-ownerless integration, meaning it will have to be addressed by the core team when they get to it. This could take months or years. Also the issue in question is a housekeeping issue. It will most likely get fixed when someone decides to update calendars. You’d be surprised how often this happens because this is the best way for new developers to get hands on experience with Home Assisant. In reality, you have 2 options, keep the issue alive when the bot responds, or let the issue fade and wait for a fix.
I also want to clarify that I’m not looking for an arugment. I’m explaining the reasoning. Please do not pick apart this reasoning as I did not come up with the system. Any comments will fall on deaf ears with me as I don’t want to argue yet another aspect of home assistant with you.
I am willing to help you get to the root of the problem though.
In relation to the issue itself, fixing this (or not fixing this) should have no impact on you as a breaking change. If you’re using it with templates, as_timestamp, as_datetime, as_local all handle isoformats that do or don’t inlcude the T, so you should be good to go regardless if this issue is alive, fixed, or not fixed. This of course is assuming that the attribute in question is a string.
If it’s a datetime object, then you are being fooled by the display. Datetime objects when displayed to the user do not include the T. You can simply test this in the template editor by using the template {{ now() }}.
You’ll notice that it doesn’t include the T, however the object type is not an isoformatted string, it’s a datetime object. Looking at the code for calendars, it seems as if these are all datetime objects indicating this is not a bug. However, I can’t confirm that because I do not use a calendar.
Either way, you can test this out by extracting the attribute in a template with {{ state_sttr('calendar.xyz', 'start_time').hour }}. If that template returns a value, then you are being fooled by the display in the states screen and there is no bug. If that template errors, then it can be considered a bug and your issue is valid.
And finally, the requirement for ISO formatting strings or supplying a datetime object is only currently applied to device_class: timestamp sensor states, not attributes.
9 Likes
no, I’m not fooled by UI. Those attribute values are passed in this form via WS api (ie to NodeRed).
The fact timestamp sensor requires iso format with time zone was triggered my issue since I copy data from attributes to timestamp sensor. It’s fair to expect all data follows the same conventions. Devs should appreciate someone found an issue related to the recent changes to timestamp format.
If it’s indeed FE or API issue, it should be analyzed by a developer and redirected if needed. Hope you don’t expect the expertise from the reporter.
Obviously none of them gonna happen for already closed issue.
I have third one: to not waste time reporting issues. Thank you.
Humor me and place those templates into the template editor and take a screenshot. I’m just curious.
If your template is returning a timestamp that should be displayed in the frontend (e.g., as a sensor entity with device_class: timestamp), you have to ensure that it is the ISO 8601 format (meaning it has the “T” separator between the date and time portion). Otherwise, frontend rendering on macOS and iOS devices will show an error. The following value template would result in such an error:
{{ states.sun.sun.last_changed }} => 2021-01-24 07:06:59+00:00 (missing “T” separator)
To fix it, enforce the ISO conversion via isoformat():
{{ states.sun.sun.last_changed.isoformat() }} => 2021-01-24T07:06:59+00:00 (contains “T” separator)
@boheme61 it’s all true but you are obviously missing the point. Read the last Pedro’s post - I’m just providing some proofs he was asking for
The thing is, HA is a community project. the devs at nabu casa are limited, the rest has probably also a fulltime job and a family and friends and they do this as hobby. a huge portion of open source software is written by hobbyists.
with HA beeing open source, you can atleast check the dev progress. if you fill in a bug report at for example microsoft, you might get just the answer that they work on it.
Also, my personal critism in the mix: HA has many different components apart from the core: supervisor, core addons, community addons, HAOS with images for different systems etc. sure, its nice to have all these possibilities, but its a huge portion to maintain. and yes, i know that HAOS for example is a good thing to provide less tech-savvy people an easy start of getting an sdcard and a pi or an old pc, flash the image and boot it right up into a minimalist OS with HA ready to rock. For my personal taste, id like to see a kind of package to install HA, maybe supervised, easier for a bit more tech-savvy people, like a custom apt repo for debian to install docker, supervised or venv/core. but who should maintain it?
sorry i forgot the point was, that auto-bot removed your reported issue
edit: im also just being curious, what happens to your template, if you add “.isoformat” as the documentation says
edit2: as i (during this)checked in sql-lite and the log after, i also started to believe it’s a “decision made” to render T to a “space” in front-end ( thx for that), but if that interfere with your “integration” or the way you want result displayed, or what’s going wrong … yes you are right, i missed the point
it doesn’t work since isoformat() is method of the datetime object while we are testing string (actually Pedro asked for the same check) Obviously string can be converted to datetime object using as_datetime function (btw this function doesn’t return iso format too, and must be treated by .isoformat() )
It mainly renders into incompatibility / inconsistency between 2 core integrations. Timestamp sensor requires iso format with time zone included. Google calendar sensor contains data without T and without time zone.
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.