System Status - Add check to ensure that MySQL timezones are operational

[totten]

Overview

Add a status check to ensure that MySQL can consistently handle TIMESTAMP data in a timezone-sensitive fashion.

The main issue is that timezone data has to be loaded into MySQL. Many platforms/environments do this automatically, but some don't.

Before

No status check. You may have random trouble because MySQL cannot accurately set the timezone.

After

If MySQL lacks timezone support, then Civi will display a warning:

Comments

I was ambivalent about whether to target 5.58 or master. The branch is based on a shared commit, so it should be easy to switch if appropriate.

[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).

[seamuslee001]

so @totten how does this improve on https://github.com/civicrm/civicrm-core/blob/master/CRM/Utils/Check/Component/Env.php#L120 or is that much different to that

[totten]

I think they're different:

• checkTimezoneAPIs() tells you that MySQL has enough information to perform TZ conversions and use symbolic timezones (e.g. America/New_York).
• checkMysqlTime() tells you that PHP and MySQL currently display "now" with matched (or mismatched) values. This does implicitly suggest that they are presenting "now" with the same offset (since, afaik, the base UF integration still uses offset to configure mysql).

They can signal different things, such as

• UF integration bug would not affect checkTimezoneAPIs() but would affect checkMysqlTime() (eg because it neglects to set one or the other)
• Missing TZ data would affect checkTimezoneAPIs() but would not affect checkMysqlTime() (eg if both set current TZ by offset)
• Highly skewed clocks (eg db server has ntpd but webserver doesn't) would affect checkMysqlTime() but not checkTimezoneAPIs()

[demeritcowboy]

Ok the permissions are good. It does though make an initially confusing fatal error entry in your logs for people who don't have timezones installed, but I think that's ok - it's not going to be on every page run, and there's similar spurious log entries for a couple other things in civi.

[error] $Fatal Error Details = Array
(
    [callback] => Array
        (
            [0] => CRM_Core_Error
            [1] => exceptionHandler
        )

    [code] => -1
    [message] => DB Error: unknown error
    [mode] => 16
    [debug_info] => SET @@time_zone = "Europe/Berlin" [nativecode=1298 ** Unknown or incorrect time zone: 'Europe/Berlin']
    [type] => DB_Error
    [user_info] => SET @@time_zone = "Europe/Berlin" [nativecode=1298 ** Unknown or incorrect time zone: 'Europe/Berlin']
    [to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="SET @@time_zone = "Europe/Berlin" [nativecode=1298 ** Unknown or incorrect time zone: 'Europe/Berlin']"]
)

One suggestion: Both the converted checks are either on the same side or the other side of DST from where you are "now". Possibly one of them should be in e.g. August, just so it's checking both sides of DST. But that's just extra since the check is really about whether you have zones loaded.

The status check level is warning, but I suppose at some point people on shared hosting without timezones are going to ask what they are expected to do. It's not written in stone yet, and this might give a better idea of who's affected. The survey earlier suggested it might not be too bad.