I recently implemented a WordPress site that integrates tightly with Salesforce.  Much of the site content is being retrieved from Salesforce on a daily basis.  The Salesforce content is retrieved and imported into WordPress via custom PHP scripts and the Salesforce API.

An interesting wrinkle comes up when importing time stamped data.  In this instance, the Salesforce data includes start dates and times for publicly accessible webinars.  Salesforce’s API was giving me the date in UTC, a.k.a., Coordinated Universal Time, which represents the same time as Greenwich Mean Time (GMT).

The web site operates in the New York time zone and serves a member base generally residing and working in that time zone, so all dates and times need to be displayed in EST/EDT.   No problem, right?  PHP gives us excellent tools for date/time math, including handling time zones.  In fact, the PHP date function, when used as date(“I”) , in a script where PHP timezone has been set to time zone with daylight savings, returns a “1” to indicate daylight savings time is in effect (4 hours behind UTC/GMT), or a “0” to indicate standard time is in effect (5 hours behind UTC/GMT).

Except it wasn’t working in my code.  After Daylight Savings went into effect on March 12th, 2017, the webinar start times were off by one hour.  A quick test of date(“I”) was returning “0”.  Why wasn’t it returning the expected “1”?.   I wrote a test script outside of WordPress, and date(“I”) did return “1”.  Different result!

Then it occurred me.  The answer was right under my nose, and something I always ignored:  In the wp_settings.php file, WordPress sets the time zone to UTC!

WordPress uses it’s own functions to calculate the time offset from UTC, based on the General/Settings Timezone value set by the site admin.

So, instead of relying on any of the built in PHP functions, if you have a script handling dates and times from a different timezone, and you need those in local time, use get_option(‘gmt_offset’) from the WordPress Codex.

Here’s the simple function I added to correctly get the time notation I need to covert to the date/time strings I was receiving from Salesforce.

For example, for a 10AM EDT start time for one of the events, Saesforce gives me 2017-03-15T14:00:00.000.

GetGMTOffset(“2017-03-15T14:00:00.000”) returns 2017-03-15T14:00:00.000+0400.

If EST is in effect, the same function returns  2017-03-15T14:00:00.000+0500.