volkswagenchick → credited mandclu → .
mandclu → created an issue.
mandclu → created an issue. See original summary → .
I have a project that started throw 15 phpcs errors of the exact type mentioned in the IS and also one other, all in .yml files. I can't personally see what useful feedback we would get from running a php check against .yml files.
This was addressed in previous commits, in particular New and updated block placement
Moving this to Event Platform since the cause probably needs a fix in the config page admin labels.
Also, updating the IS to reflect the new understanding, as well as the fact that the order of the fields has changed.
seantwalsh → credited mandclu → .
seantwalsh → credited mandclu → .
Ironic to have a typo in the issue name lol
mandclu → created an issue. See original summary → .
jdleonard → credited mandclu → .
Adding a patch for composer patching
Question: are you testing the same ics file for both Apple Calendar and Outlook? By design this module generates an ics already optimized for Outlook if you click the Outlook link, so it should already be doing a lot of the things in the linked PR.
The change actually broke the all day tests, so I updated the test. I verified that core date-only ranges store the start and end as the same value for single-day events, so the upside is that the test data now matches that.
I also left one test with different start and end dates, but updated the expected markup to reflect a two-day event. I thought it made sense to have test coverage of a multi-day event.
I've manually verified the updated links in Google and Apple Calendar, but still need to verify them with Outlook.
After some additional testing, it turns out that the previously cited issue about all day events including times was specific to core date fields, and is actually an upstream bug with Smart Date. It has been fixed in 🐛 Core date-only fields should always show as all day Active .
Updating this issue to focus on "adding one day", which still needs to be fixed here.
I'm not entirely sure we shouldn't also be applying some form of conversion for core datetime values, but the changes here do address the specific problem with date-only fields.
@jonathanshaw thank you for all your work on this. Merged in, and I will try to get a new release out shortly.
jurgenhaas → credited mandclu → .
mandclu → created an issue.
@bramvandenbulcke thank you for the work you've put into testing this. When I hear about times being an hour off, I am tempted to think that it could be an issue with daylight savings time.
I came across this thread which makes it sound as though Outlook has had an issue for some time with this, but unfortunately no solution was ever provided there.
I also found this thread which shows the contents of an ics file that includes a section that defines sections for normal and daylight savings time:
BEGIN:STANDARD
DTSTART:20250406T030000
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
TZNAME:AEST
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20241006T020000
TZOFFSETFROM:+1000
TZOFFSETTO:+1100
TZNAME:AEDT
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=1SU
END:DAYLIGHTThat appears to be specifically relevant to recurring events, however, and in the context of that thread doesn't appear to be sufficient to prevent the time added in Outlook from being off.
That does give me an idea, however. What if you tried manually changing the timezone section of your ics file from this:
TZID:Europe/Brussels
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0200
END:STANDARD
END:VTIMEZONE
to this?
TZID:Europe/Brussels
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
If that works, we would need to figure out how to manually add this additional DST-related timezone information into the generated ics files.
mandclu → created an issue.
Thanks for identifying this, and for providing a fix. Merged in, and I will roll a new release shortly.
mandclu → made their first commit to this issue’s fork.