Only AirBnB iCalendars are supported

[IanAdd]

I went to change the timezone of my two calendars which were working fine.
Amended airbnb no problem, just selected the timezone from the list and submitted, no other items touched.
Amending my Tripadvisor calendar's timezone and the message above popped up. Actually I'm unable to 'submit' even without making any change.

[IanAdd]

As an aside...
Having changed the timezone on airbnb...
The event sensor state shows the date and time unchanged but the start and end attributes have the timezone and hence will show the HA user local time in a browser when the event will happen.
I am happy with this, I just wanted to confirm this was your intention so I could code appropriately from these.
Eg.

[tykeal]

@IanAdd the error isn't actually very clear as to what is happening. When you try to submit the integration validates that the provided URL complies with the following two rules (text for both is being updated in #75)

1. the URL is an https url. Non-https URLs are rejected
2. the URL returns a content type of text/calendar. I would expect TripAdvisor to do this properly. To figure out what is happening we need to know what the 'Content-Type' that TripAdvisor is returning. The easiest way is the following (assuming a Linux or Mac with the appropriate utilities installed)

HEAD the_url | grep -i content-type

For instance AirBnB returns the following with that command:

Content-Type: text/calendar;charset=utf-8
X-Content-Type-Options: nosniff

Whiel VRBO and Guesty return the following (respectively):

Content-Type: text/calendar;charset=UTF-8
Content-Type: text/calendar

Alternatively, you can email me (or PM me on the HA forums) a URL that I can go and inspect for any oddities.

As to your aside. Yes, that is sort of intended. What happens is that the selected timezone is applied to the calendar on the next calendar refresh (roughly every 2 minutes). Sensors refresh every 30ish seconds. The state description when it is being built is ignoring the the timezone in the date and time string conversion for the status. So it's going to effectively treat it as the timezone of the object is the "local" timezone for output.

However, the start and end times are timezone aware and are treating everything correctly.

Personally, I don't have calendars that are in timezones other than my local, but in my manual testing I've been adding one and sticking it on the other side of the world from me so that I can make sure that the objects that it really matters for are updating correctly. Having the status show the date time as the local to property makes it easier to know that it's doing the correct(ish) thing, particularly in the case where you might need to talk to a guest. You don't have to do the timezone conversion yourself then.

[tykeal]

This issue was resolved with a combination of #75 and #77