Don't prefix iCal Timezones with / for better compatibility
The TZIDs in https://dev.twitch.tv/docs/api/reference/#get-channel-icalendar are currently prefixed by a / so they are /America/New_York for example. Removing the leading slash should vastly improve compatibility with iCal parsers (since the timezones are essentially IANA timezones then).
According to RFC5545 `The presence of the SOLIDUS character as a prefix, indicates that this "TZID" represents a unique ID in a globally defined time zone registry (when such registry is defined).` (note: SOLIDUS character is defined in this RFC as decimal codepoint 47 `/`).
So using the `/` prefix is "correct". However RFC5545 explicitly mentions it does *not* specify any such globally unique time zone identifiers and that it's left "for future study", it also doesn't provide a way to reference a time zone registry. As far as I'm aware there also isn't a RFC that 'updates' RFC5545 to either specify a specific global time zone registry to use or how to reference one.
Therefore iCalendar parses which only implement the RFC don't have a single agreed upon time zone registry to use. I believe Google Calendar and some parsers do use a registry but it is *not* standardized. Many parses require that each unique TZID used in a iCalendar has a corresponding VTIMEZONE included in the iCalendar because they don't use the (undefined) global registry. Or to quote the RFC description of TZID parameter: `This property parameter specifies a text value that uniquely identifies the "VTIMEZONE" calendar component to be used when evaluating the time portion of the property. The value of the "TZID" property parameter will be equal to the value of the "TZID" property for the matching time zone definition. An individual "VTIMEZONE" calendar component MUST be specified for each unique "TZID" parameter value specified in the iCalendar object.`
Please explicitly include time zone definitions ("VTIMEZONE" components) inside the iCalendar returned by the API endpoint.
This easy inclusion should fix all time zone (conversion) problems for all RFC5545 compliant parsers.