When I began troubleshooting this issue, I viewed the lack of a value for gmt_offset as the culprit, and considered the server to be solid. But after I updated the gmt_offset value in the database and the error persisted, I knew I’d been mistaken.
An admin had posted to a WP forum indicating that, despite having a valid timezone, things were amiss. His issue was circular soft-linking of timezones (America/New_York linked to EST, which itself was a softlink that linked back to America/New_York). Upon reading that, I’d confirmed that this wasn’t the case on my own server.
However, coming back to checking over the system, I noticed that when I compared permissions of the timezone files (yes, it’s always permissions) on another environment (which was working fine), I noticed this discrepancy between the working environment (top)…
]# ls -alh /usr/share/zoneinfo/America/Phoenix
lrwxrwxrwx 1 root root 15 Aug 31 13:40 /usr/share/zoneinfo/America/Phoenix -> ../SystemV/MST7
]# ls -alh /usr/share/zoneinfo/SystemV/MST7
-rw-r--r-- 1 root root 353 Jul 4 14:46 /usr/share/zoneinfo/SystemV/MST7
… and the problem server…
]# ls -alh /usr/share/zoneinfo/America/Phoenix
lrwxrwxrwx 1 root root 15 Jul 4 14:46 /usr/share/zoneinfo/America/Phoenix -> ../SystemV/MST7
]# ls -alh /usr/share/zoneinfo/SystemV/MST7
-rwxrw---- 1 root root 353 Jul 4 14:46 /usr/share/zoneinfo/SystemV/MST7
chmod 644 and problem resolved.