Fix UTC offsets when retrieving timezone string in WordPress

[christianwach]

Overview

Fixes this issue on Lab.

Before

In WordPress, one can choose e.g. UTC+4 as the site's timezone. This results in no value being returned by get_option('timezone_string') which may lead to unexpected results in CiviCRM.

After

When choosing e.g. UTC+4 in WordPress, a deprecated (but still currently valid) Etc/UTC-4 timezone string is used.

Comments

There is a companion PR in the CiviCRM-WordPress repo.

[civibot]

(Standard links)

• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[eileenmcnaughton]

@christianwach ping me if you need help getting this merged - I'm kinda assuming @kcristiano will merge it

[demeritcowboy]

I also took a quick look just haven't had a chance to run yet but the idea looked good.

[christianwach]

@eileenmcnaughton Thanks - @kcristiano wants to err on the side of caution and run it in some production contexts before merging. Similar code is actually in a number of relatively high profile WordPress plugins, so I'm confident he'll find it works as expected.

EDIT: This shouldn't be a substitute for people setting a named timezone in their WordPress site settings 😄

[kcristiano]

Thanks @eileenmcnaughton I'll add merge-ready once I am ready to merge these.

[demeritcowboy]

I did a quick little run. For example for this core PR part of it, creating an activity via command line and leaving the date blank sets the activity date to the wrong time currently, and with the PR sets it according to the configured offset.

[kcristiano]

Thanks @demeritcowboy I've also done a number of test and r-run I was waiting on one last test on a staging site that has a custom implementation using the API but this looks good to merge.

[kcristiano]

@eileenmcnaughton if you can merge this I can merge civicrm/civicrm-wordpress#298