Threads that are not resolved should no be closed.

[Douglas]

Just to clarify. The date issue only appears on the Facebook import screen. The population of the same value in start and end time/date is a product of your tool when it imports the event… If the end time/date shouldn’t be populated your import should not populate it.. Manually intervention is not an acceptable solution. It means it’s not automated at two levels. After manually importing as well auto importing.

I did change the date to -8 UTC and reran the Facebook import and the import screen did not change. That date on that screen is being displayed from the graph API interigation and not a field on the event data base.( my assumption) The event can be removed and reimported with the same results.

[George]

Thanks for testing this Douglas.

With all of the same settings I have not yet personally created the issue on my own local site, but I am not doubting the existence of this bug. The related code is this line of code from Importer.php, inside the Facebook Importer add-on of ours:


$start_date = date_i18n( $this->date_format, strtotime( $fb_event->start_time ) );


That bit of code, $fb_event->start_time, is indeed where the discrepancy seems to be arising from.

I will create a bug ticket for our developers to investigate this more closely, though I’m afraid at this time there aren’t any other immediate courses of action I can recommend.

I’m sorry about this state of things. There are essentially two bugs now, both of which we have to work on bugfixes for and release those fixes in upcoming releases of the plugins. I do not have ETAs on these fixes, though Brian has already shared a code solution for the first bug and so that fix should be included in the very next release coming out. I hope the same for the second bug.

Thank you,
George

[Author]

Posts