Hi Bart,
I already emailed an epic (via Andrew G, 'cause I found I didn’t have your direct email), but I’ll put some responses here for the record as well.
The paint layout I’m using is: #2776846 on cms.unimelb.edu.au - it’s a bit of a mish mash, but I get away with it because it is single purpose. Assets have a user specified design and paint layout, so URLs have
?SQ_DESIGN_NAME=ical&SQ_PAINT_LAYOUT_NAME=ical
appended.
The design is just:
<MySource_PRINT id_name="__global__" var="content_type" content_type="text/calendar" />
<MySource_AREA id_name="body" design_area="body" />
which initiates a download immediately.
–
For the incorrect time thing, I checked again, and it definitely looks like a bug:
In the Description field of my Calendar event, I have:
event_start_datetime: %event_start_datetime%
event_start_time_ical: %event_start_time_ical%
but my front end output is:
event_start_datetime: 30 Oct 2019 9:15 AM
event_start_time_ical: 20191031T101500
The first keyword event_start_datetime
is returning the non-daylight savings time. You can see this on my asset: Across daylight savings #3147209.
–
Finally yes. TZID sets the timezone of an event, but an ical file is a complete self contained calendar.
The timezone needs to be defined at the calendar level or it doesn’t understand what you mean when you specify a timezone in an event. https://www.kanzaki.com/docs/ical/vtimezone.html
At the calendar level, you define all the timezones you want to use in a VTIMEZONE - a bit like classes in a css file. Then, at the event level, you can specify (with TZID) which timezone each event belongs to by name.
Just like CSS - if you refer to a TZID that you haven’t defined in the calendar, it’s just ignored.
The rules in a VTIMEZONE must include all the information required for the event to be defined. So, using my daylight savings example above - my VTIMEZONE would need to define AEST as +10 and AEDST as +11. Without both of these, it wouldn’t be able to make sense of me adding an event now (in a period not covered by daylight savings) for a calendar event in the future (in a period covered by daylight savings).
Horrible, innit?
You can see why a metadata schema just isn’t going to cut it. There are so many variables!
Cheers, Andrew