CRM-21422 - Fix handling of 0 timezone offset

[aydun]

Overview

Fix 'Timestamp Mismatch' warnings for servers with 0 timezone offset for UTC - eg Europe/London (when no daylight savings in effect), AND where the server timezone is different.

Before

Timestamp Mismatch warning

After

No Timestamp Mismatch warning

Technical Details

If the PR introduces noteworthy technical changes, please describe them here. Provide code snippets if necessary

Comments

Anything else you would like the reviewer to note

---

• CRM-21422: TimeZone handling for Europe/London fails

[eileenmcnaughton]

So I understand you are saying '0' is a legit offset & should be treated as such. 2 things

1. it would be better to use === since this is a specific value we accept.
2. your pr comment says 'AND where the server timezone is different.' - but we want warnings to show if the server timezone differs.... is the pr comment correct?

[aydun]

Thanks @eileenmcnaughton. Yes, a '0' offset is legit.

The specific scenario is:

• system timezone is 'Europe/Sofia' and cannot be changed (shared hosting)
• php.ini and Drupal are configured to 'Europe/London'
• The offset at this time of year from 'Europe/London' to UTC is 0, but getTimeZoneOffset() returns false instead of '+00:00' causing the MySQL 'SET time_zone = ...' to be skipped in setMySQLTimeZone() so the SQL results default to 'Europe/Sofia' triggering the 'Timestamp mismatch' warning.

So:

1. code changed
2. I'm meaning that the change should not affect the results were the system timezone is the same as the php/Drupal one. If the system timezone is the same, and the offset is 0, it still skips setting the MySQL timezone but the times are returned correctly as a result of the system timezone and the 'Timestamp mismatch' warning is not triggered. Any better ways of expressing that welcome!

[eileenmcnaughton]

Ok that makes sense & I think this is a logical change which should not have adverse consequences. Merging