Timezone selection not working properly

Hey, I had the exact same issue today. I was able to get my Google .ics to import correctly by removing lines 69-74 in /src/Feeds/Parser/IcalParser.php, i.e.:

                    case 'dtstart':
                        $itemObject->set($eventProperty, $event->dtstart_array[2]);
                        break;
                    case 'dtend':
                        $itemObject->set($eventProperty, $event->dtend_array[2]);
                        break;

Just delete those lines and leave everything else as is, and the time zone handling should work fine. Hope this helps!

@tamarckmedia @ablum I added this as a patch. Any testing you wanted to do on it would be appreciated, especially on use cases besides the one that lead to finding this issue.

While this does fix the timezone issue it breaks All Day events, making the date set to August 22, 1970 with all kinds of different times.

I updated the patch to take this into account and while it's probably not the most elegant solution it works. I took advantage of All Day events not having a time set so that these events get the Unix timestamp while the other events get the ISO standard pulled over. This basically sets the All Day events to midnight and the other events to whatever time they need to be based on the ISO standard.

This patch worked for me. Huge thank you.

@catapipper Thank you, patch #6 works for me with Feeds iCal 8.x-1.2.

With or without patch #6 I have a php notice (see below). It works fine with periodical background import (just a notice in dblog), but break manual import with batch.
I believe empty dtend_array event property comes from the feed source - when end date is empty.

Patch is attached. It's not related to the patch #6 or issue in this thread. But it changes the same code as the critical patch #6. So I've just updated it to avoid conflicts.

Notice: Undefined property: ICal\Event::$dtend_array in Drupal\feeds_ical\Feeds\Parser\IcalParser->parse() (line 73 of /code/web/modules/contrib/feeds_ical/src/Feeds/Parser/IcalParser.php)
#0 /code/web/core/includes/bootstrap.inc(600): _drupal_error_handler_real(8, 'Undefined prope...', '/code/web/modul...', 73, Array)
#1 /code/web/modules/contrib/feeds_ical/src/Feeds/Parser/IcalParser.php(73): _drupal_error_handler(8, 'Undefined prope...', '/code/web/modul...', 73, Array)
#2 /code/web/modules/contrib/feeds/src/EventSubscriber/LazySubscriber.php(85): Drupal\feeds_ical\Feeds\Parser\IcalParser->parse(Object(Drupal\feeds\Entity\Feed), Object(Drupal\feeds\Result\HttpFetcherResult), Object(Drupal\feeds\State))
#3 [internal function]: Drupal\feeds\EventSubscriber\LazySubscriber->Drupal\feeds\EventSubscriber\{closure}(Object(Drupal\feeds\Event\ParseEvent), 'feeds.parse', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#4 /code/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Object(Closure), Object(Drupal\feeds\Event\ParseEvent), 'feeds.parse', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#5 /code/web/modules/contrib/feeds/src/Event/EventDispatcherTrait.php(38): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('feeds.parse', Object(Drupal\feeds\Event\ParseEvent))
#6 /code/web/modules/contrib/feeds/src/FeedsExecutable.php(239): Drupal\feeds\FeedsExecutable->dispatchEvent('feeds.parse', Object(Drupal\feeds\Event\ParseEvent))
#7 /code/web/modules/contrib/feeds/src/FeedsExecutable.php(106): Drupal\feeds\FeedsExecutable->doParse(Object(Drupal\feeds\Entity\Feed), Object(Drupal\feeds\Result\HttpFetcherResult))
#8 /code/web/modules/contrib/feeds/src/Plugin/QueueWorker/FeedRefresh.php(36): Drupal\feeds\FeedsExecutable->processItem(Object(Drupal\feeds\Entity\Feed), 'parse', Array)
#9 /code/web/core/lib/Drupal/Core/Cron.php(180): Drupal\feeds\Plugin\QueueWorker\FeedRefresh->processItem(Array)
#10 /code/web/core/lib/Drupal/Core/Cron.php(145): Drupal\Core\Cron->processQueues()
#11 /code/web/core/lib/Drupal/Core/ProxyClass/Cron.php(75): Drupal\Core\Cron->run()
#12 /code/web/core/modules/automated_cron/src/EventSubscriber/AutomatedCron.php(65): Drupal\Core\ProxyClass\Cron->run()
#13 [internal function]: Drupal\automated_cron\EventSubscriber\AutomatedCron->onTerminate(Object(Symfony\Component\HttpKernel\Event\PostResponseEvent), 'kernel.terminat...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#14 /code/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\PostResponseEvent), 'kernel.terminat...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#15 /code/vendor/symfony/http-kernel/HttpKernel.php(88): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.terminat...', Object(Symfony\Component\HttpKernel\Event\PostResponseEvent))
#16 /code/vendor/stack/builder/src/Stack/StackedHttpKernel.php(32): Symfony\Component\HttpKernel\HttpKernel->terminate(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\big_pipe\Render\BigPipeResponse))
#17 /code/web/core/lib/Drupal/Core/DrupalKernel.php(686): Stack\StackedHttpKernel->terminate(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\big_pipe\Render\BigPipeResponse))
#18 /code/web/index.php(22): Drupal\Core\DrupalKernel->terminate(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\big_pipe\Render\BigPipeResponse))
#19 {main}

Patch #8 didn't apply for me on 2.04 because of a single space. Attaching a fix!

Sorry, messed #9 up...this one should work.

This new MR addresses the timezone issue more directly. Checking for "T" isn't reliable given the various forms of date strings we might see, including something like "DTSTART;TZID=America/New_York:19980312T083000"

The ICal\ICal class provides the timezone in the date arrays like
Array ( [0] => Array ( [TZID] => Europe/Berlin ) [1] => 20240410T140000 [2] => 1712750400 [3] => TZID=Europe/Berlin:20240410T140000 )

In this way, we can identify if a timezone was provided and use it appropriately, which in the case above involves formatting the date string like:
20240410T140000Europe/Berlin

See related Feeds issue: https://www.drupal.org/project/feeds/issues/3070757

With this MR, formatting using the provided timezone results in the Feeds DateTargetBase class creating the date using the provided timezone. See: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Datetime%...

"Note that the $timezone parameter and the current
* timezone are ignored when the $time parameter either is a UNIX timestamp
* (e.g. @946684800) or specifies a timezone
* (e.g. 2010-01-28T15:00:00+02:00)."

In my testing imported events without timezone were unaffected, while events with them were adjusted accordingly to match my site's default setting.

If I could get some testing here that would be awesome! Thanks!

In my Feeds mapping I have selected DTSTART (unix timestamp) and when there is a timezone in the feed I am now getting a string such as 20250405T120000America/New_York, which is causing fatal PHP errors when I pass it to date(). This is almost certainly a change in behavior. There is a mapping for DTSTART RAW (string format from source) but I have never used it.

Feeds that don't use a TZID specification continue to return the timestamp to my processor as always.

Of course, correct processing of timezone is important, but I hope we can keep the behavior of returning a unix timestamp when specified.

Thanks @peter pulsifer I will take a look at this tomorrow. That mapping should indeed pass the timestamp directly.
Are you able to share an example .ics / .ical that you're working with?

Thanks @ben.hamelin. One example feed is https://griffinmuseum.org/events/?ical=1.
This one has no TZID and the importer gives the timestamp: http://api.membershipworks.com/v2/events?_op=ics&org=14015

@peter pulsifer Sorry I am battling with Gitlab.... going to open a new issue so this is quicker. I can't seem to rebase the issue fork from the source project from the Gitlab UI.

https://www.drupal.org/project/feeds_ical/issues/3517541