plugin is conflicting with Event Espresso

Hi midsouthflyfishers,

Could you have a look and see what your wordpress timezone settings are ? In the settings > general section of wordpress admin?
And if EE has timezone settings, what they are ? Are they the same?

Ical events Plugin looks for either gmt_offset or actual timezone in a sites wordpress options. If not found it will use the php default for your server. This should be in sync with what wordpress uses for posts etc so post dates and event dates will make sense together.
(It does set the default timezone for the page as ‘insurance’ because getting the timezone right consistently is crucial else hours will be off as you have noted. This is especially important for events that are to be viewed by people in different timezones ) Ical events list plugin has been stable timezone/hours wise for a few years now.

So I’m guessing here but one possibility is that event espresso perhaps uses some other timezone (maybe UTC ?) and is not grabbing the wordpress or php timezone? and then may be that maybe somehow the plugins are loading in different sequences at different times and sometimes mine has set the default before ee gets loaded and sometimes not? or maybe its a save vs dispaly thing? And maybe if EE is not particularly specifying a timezone somewhere, then things could get confusing.

To fix: wp and ee should use the same timezone. (My plugin will use what wp is using, so that should fix any discrepancy).
According to this:
https://eventespresso.com/topic/dealing-with-timezones/ it appears that the EE timezone can be set. So set it to the wp timezone and all should be fine.

Other recent EE timezone posts:
https://eventespresso.com/topic/setting-timezone-ee4/
https://eventespresso.com/topic/timezone-issue/
https://eventespresso.com/topic/time-zone/

(aside: ?? the amr-events plugin that lets you create events in wordpress allows you either just to use default wp timezone, or set the timezone or have a ‘floating’ timezone that would be the same whatever the timezone of the page. It then converts and displays events either in wp or in a special timezone for page and you can also display the timezone of the event if necessary. )

Thank you for your reply. I will forward your comments to the folks at EE to see what they say.
To Answer your questions, My timezone is set to America/Chicago in WP settings.

This is what I show from the Plug In page advanced settings

Your php version is: 5.4.23
Your timezone db version is: 2013.8
Php timezonedb versions Info on what changes are in which timezonedb version
The plugin thinks your timezone is: America/Chicago Go to settings
The current UTC offset for that timezone is: -5
Switches to standard time on 02 Nov 2014 @ 01:00. GMT offset: -6
Current time (unlocalised): Wed, 18 Jun 2014 17:35:22 -0500

Choose date localisation method:?

none – Wed, 18 Jun 2014 17:35:22 -0500
amr – Wed, 18 Jun 2014 17:35:22 -0500
wp – Wed, 18 Jun 2014 17:35:22 -0500
wpgmt – Wed, 18 Jun 2014 22:35:22 +0000

I looked at this section when it was 5:35 central standard time. Would all of that look as you would expect it to look?

Regarding the EE settings, there was talk in their forums on TZ settings, but I did not see those settings in the version that I am running. (it’s a newer version).

Just a few questions…
When you say the plugin sets the default tz for the pages, would that apply to mgmt pages as well? (forgive me if the questions are dumb, I do not have a development bkground)

If so, is there any way to selectively disable this as a potential workaround until a final root cause is determined and fixed, without any harm to the plugin functionality (all my traffic, calendar stuff, etc will be in central time as we are a small local club)

Finally, would you mind keeping the issue open so I can bounce questions back and forth between the EE folks and yourself?

Thank you for your time, it is appreciated.

Hi midsouthflyfishers and anmari,

I’m the lead Dev for Event Espresso.

The reason that the amr_set_defaults_for_datetime() function is throwing off your Event Espresso datetimes is because it uses the PHP function date_default_timezone_set() which is highly discouraged by WordPress.

see:

• https://vip.wordpress.com/documentation/use-current_time-not-date_default_timezone_set/
• https://weston.ruter.net/2013/04/02/do-not-change-the-default-timezone-from-utc-in-wordpress/
• https://www.taupecat.com/2010/10/using-time-in-your-wordpress-plugin/

WordPress expects the timezone to ALWAYS be set to UTC+0, and as you can read in the last article I linked to, it is the official position of the core WordPress developers.

If you need to adjust the timezone, your best bet is to create PHP Datetime objects (see: https://www.php.net//manual/en/class.datetime.php) which allows you to set the timezone for each object.

Overriding the base WordPress timezone with date_default_timezone_set() throws everything off and should never be done.

Event Espresso 3 at one point used date_default_timezone_set() and it caused problems for other plugins, so we know all about this issue.

In Event Espresso 4, ALL of our datetime fields in the db are now stored in UTC+0 and then have their timezone offset applied immediately after being pulled from the db. For some of our larger clients running events in multiple timezones, this is the only possible way to handle this correctly.

Hope this helps.

Hi Brent,

Thanks for contributing here.

As those posts note, ‘surprising’ (as in i’m surprised too :). I see why it is so – probably due to older php versions not having the date/timezone objects (problems could have been avoided by simply knowing/keeping the timezone info with any date). Anyways… it is what it is… so the ‘date default set’ will have to go.

My plugin should be ok removing those lines as it does have it’s own timezone object and it should be using that everywhere. However when something has been there for so long, I’m always wary that something might break (ie was relying on it when it should not be).

So I will obviously run some tests first to be sure everything is independent of it.

So midsouthflyfishers,

for a quick interim resolution for you, I see some options in no particular order:

1) not ideal, but if possible(?) set wp and ee timezones to UTC so all bits of software are on same timezone until an update comes through.

2) if you are in middle of testing anyway, delete lines 309 and 317 that have date_default_timezone_set in amr-ical-config.php and test thoroughly your ics file events display with a range of date types (recurring series over daylight saving date changes etc) and timezones to make sure all is ok. (let me know please how that goes)

3) we may be able to do some testing on this removal over the weekend, so you could wait and I’ll let you know. It takes a while because the plugin copes for a range of timezone related ‘features’ which makes for tricky test data and testing eg:

https://icalevents.com/2242-importance-of-timezones-in-recurring-events/
https://icalevents.com/3521-how-event-timezones-work/

Hi anmari,

Collectively, the Event Espresso tEEm has spent hundreds of hours wrestling with datetime and timezone issues (it gets even trickier when you roll translations and PHP 5.2 into the mix – yuk) so I understand how you can be wary of changing something that, for the most part, has been working for you. I feel your pain, I really do.

Anyways, one thing that I forgot to mention in my first post is that the ONLY real reason you need to use date_default_timezone_set() is if you are using the PHP date() function anywhere in your code, and need to have the dates it produces corrected for your timezone offset. So removing date_default_timezone_set() is fine, but you will ALSO have to search through your plugin, and as the first article I linked to on the WP VIP site stated, use the WP current_time() function instead of date(). The current_time() function will apply the WP timezone offset that is saved in the WP settings.

You can find the current_time() function in wp-includes/functions.php.

Hope that helps a bit more.

Take care and good luck.

thanks brent – mostly all in date objects not timestamps, except have to convert to timestamps for the localisation.

hi midsouthflyfishers

I have a draft update that seems to be doing the right thing. I will be doing more formal testing before releasing but if you interested in a preliminary update, feel free to email me at [email protected].

Sure thing. I’ll shoot you an email and let you know how it goes from my end.
Wanted to say thanks to everyone for the collaboration.

Just wanted to update. I installed version 4.7 beta on my site. It seems to have fixed the issue with Event Espresso and the core functionality of the plugin seems to be unaffected. My pages that are using the plugin still look good and the data displays correctly. Everything looks great from my end.

Thanks for your help.

Thanks 4.7 is up – a few minor differences (RDATE) to 4.7 beta

Thanks I’ll install it. Everything looks resolved on my end. thanks again for your help.

Hey Brent, I know this thread is 6 months old, but hopefully you are still subscribed to it. Would you be able to tell me if version 3.1.36.3.P of Event Espresso still uses the PHP function date_default_timezone_set() ?

This is the version I have, and our support licence just ran out about a week ago so I can’t update it.

I am asking because I am experiencing a similar conflict with a different plugin, Bookly, causing the appointment times on Bookly to be offset by 8 hours and the issue goes away when EE is deactivated.