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.
