Currently, DatabaseMysqlBase does not set the time_zone setting, meaning the server's configured time zone will be used. This may or may not be UTC (+00:00), which is problematic in the few places where an actual timestamp column is in use (rather than binary(14), varbinary(14), or datetime), as most MediaWiki code assumes UTC.
For example, on my system, the query SELECT MIN(cl_timestamp) FROM categorylinks WHERE cl_to = 'All_stub_articles', when run against an enwiki DB dump from October 2015, returns 2014-06-17 05:11:10, because time_zone is SYSTEM and system_time_zone is EST. The actual UTC value stored by MySQL or MariaDB is 2014-06-17 09:11:10.
Fixing new data could be done by having MediaWiki set time_zone, though is that going to cause problems with statement-based replication? Would it be better to switch to one of the other types instead of or in addition to this?
Fixing existing data may require a script to be written to adjust categorylinks.cl_timestamp, as well as at least some of these columns in extensions' tables (which will have to be checked individually). However, it would be hard to be sure any adjusted timestamp is correct because the timestamp may have been generated either by MediaWiki or the server, and the server's time zone could have changed after the timestamp was stored.
- FlickrAPI: FlickrAPI.expiration
- GooglePlaces: GooglePlaces.expiration
- MathSearch: mathlog.math_timestamp,mathperformance.timestamp, mathindex.mathindex_timestamp, mathobservation.mathobservation_timestamp
- UIFeedback: uifeedback.uif_created, uifeedbackreviews.uifr_created
See also: T42626: Standardise type of timestamp database fields (MySQL)