Google Calendar cannot import time zone description

[dg76]

Hi!

I am not sure if this is a new problem in Google Calendar but it seems now that it does not like the TZID in the time zone definition block when importing an ICS file generated by this library. The events of the ICS file are not displayed in Google Calendar if the time zone block looks like this:

BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:STANDARD
DTSTART;TZID=+00:00:20201025T010000

It works fine when using an UTC time instead:

BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:STANDARD
DTSTART:20201025T010000Z

The file CalendarExport.php creates the upper block in "local-tz" mode:

if ($this->dateTimeFormat === 'local') {
    ${$varName}['start'] = ':' . $this->formatter->getFormattedDateTime(new \DateTime($transition['time']));
} else if ($this->dateTimeFormat === 'utc') {
    ${$varName}['start'] = ':' . $this->formatter->getFormattedUTCDateTime(new \DateTime($transition['time']));
} else if ($this->dateTimeFormat == 'local-tz') {
    ${$varName}['start'] = ';' . $this->formatter->getFormattedDateTimeWithTimeZone(new \DateTime($transition['time']));
}

I would suggest to use the same mode as in "utc" to fix this:

if ($this->dateTimeFormat === 'local') {
    ${$varName}['start'] = ':' . $this->formatter->getFormattedDateTime(new \DateTime($transition['time']));
} else if ($this->dateTimeFormat === 'utc') {
    ${$varName}['start'] = ':' . $this->formatter->getFormattedUTCDateTime(new \DateTime($transition['time']));
} else if ($this->dateTimeFormat == 'local-tz') {
    ${$varName}['start'] = ':' . $this->formatter->getFormattedUTCDateTime(new \DateTime($transition['time']));
}

What do you think? Or is there a reason why getFormattedDateTimeWithTimeZone was used instead?

[dg76]

#54

[jasvrcek]

@dg76 see #21, we do need to offer the option of using the three different date formats. If you want to use UTC, you can just set the CalendarExport instance to use UTC:

$calendarExport->setDateTimeFormat('utc')
  ->getStream()
;

[dg76]

But that will also change the DTSTART format of the events and I would like these entries to keep the time zone. Maybe I will have to examine further which system (Google Calendar, GMail, Apple iCloud, Apple Mail, Microsoft Outlook) likes which format. E.g. when creating ICS files to attach them to an email and to allow users to import it, it was important to use the "local" format (not "local-tz") otherwise Gmail does not display the event.

Ok, if you made it on purpose this way then just reject my pull request and I will keep the change only in my personal fork. I don't know why Google Calendar does not support that time zone definition format. And yes, it works fine with the "utc" format but I need to examine first if that has maybe other side effects.

Thank you very much for your quick response! :-)

[jasvrcek]

@dg76 thanks for using this - if you find out more about your issue please go ahead and post to this thread!

[icvalyssa]

I had this issue as well. I am setting the timezone, as well as dateTimeFormat == 'local-tz'. I need to use 'local-tz' because I found I needed the inline TZID in the VEVENT DTSTART/DTEND in order for it to work in MS apps, and that does work:

BEGIN:VEVENT...
DTSTART;TZID=America/Los_Angeles:20201105T090000

However, when the dateTimeFormat == 'local-tz', it also tries to apply it to the VTIMEZONE block, but the timezone format is different and incompatible with Google:

BEGIN:VTIMEZONE
TZID:America/Los_Angeles
BEGIN:STANDARD
DTSTART;TZID=+00:00:20201101T090000

I could be wrong, but I don't think the VTIMEZONE DTSTART needs the inline TZID because the TZID is already specified in its own line in the VTIMEZONE block. I ended up using the version at commit a68469b, which includes a "fix" that omits the inline TZID from the VTIMEZONE DTSTART. This version works for me in both MS and Google apps. But the fix was reverted later on.

[jasvrcek]

@icvalyssa do you have the bandwidth to fix the issue with #47? I'll merge it in if you can.

[StewPoll]

@icvalyssa Just to make a quick comment regarding the inline timezones, I believe I found that this helps resolves issues with Outlook and events that occur on "the other side" of daylight savings.

So if you're currently going through daylight savings, and looking at an event that occurrs when there's no daylight savings, in my experience without the inline timezone information, outlook tries to correct the date/time even when it's not needed.

The inline timezone helped prevent this from happening.

(Or something to that affect... I'm certain the need for it was daylight savings and outlook related)