Ignore --default-time-zone option at setup

[yannoff]

Fix for issue #543

[tianon]

Given that simply setting the "TZ" environment variable appropriately fixes this issue without doing complex hacks like parsing the command line (which wouldn't account for this setting in a configuration file, for example), I'm opposed to going to this effort. If anything, I think "mysql_install_db" should perhaps be updated to ignore this flag until timezones are imported.

[tianon]

Given that https://dev.mysql.com/doc/refman/8.0/en/time-zone-support.html explicitly documents the TZ environment variable as a sane and reasonable way to set the timezone for mysqld, I'm going to close this.

The maintenance burden (and fragility aspect) of adding additional behavior to workaround to what amounts to a quirk of mysql_install_db is too much especially when there is a perfectly acceptable and "hack-free" solution provided by MySQL itself (namely the above-documented TZ variable, which is officially documented at least as far back as MySQL 5.5: https://dev.mysql.com/doc/refman/5.5/en/time-zone-support.html).

[robbytx]

@tianon In my experience, TZ is not sufficiently equivalent to --default-time-zone.

When I run MySQL with TZ=America/Chicago, it starts with the following variables:

mysql> show variables like '%time_zone';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CDT    |
| time_zone        | SYSTEM |
+------------------+--------+

When I run MySQL (outside Docker) with --default-time-zone=America/Chicago, it starts with the following variables:

mysql> show variables like '%time_zone';
+------------------+-----------------+
| Variable_name    | Value           |
+------------------+-----------------+
| system_time_zone | CDT             |
| time_zone        | America/Chicago |
+------------------+-----------------+

From what I can tell, the system_time_zone is inferred on startup based on the current time zone offset (and DST rules?), so MySQL picks the first matching name "CDT". In contrast, the default-time-zone name is explicitly preserved.

This difference has an impact on the MySQL JDBC client driver, which:

• happily accepts "America/Chicago", since that is an official time zone name (https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)
• fails to open connections with "CDT":

Unable to obtain Jdbc connection from DataSource
------------------------------------------------
SQL State  : 01S00
Error Code : 0
Message    : The server time zone value 'CDT' is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support.

...
Caused by: java.sql.SQLException: The server time zone value 'CDT' is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support.
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:965)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:898)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:887)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:861)
	at com.mysql.jdbc.TimeUtil.getCanonicalTimezone(TimeUtil.java:455)
	at com.mysql.jdbc.ConnectionImpl.configureTimezone(ConnectionImpl.java:1970)
	at com.mysql.jdbc.ConnectionImpl.initializePropsFromServer(ConnectionImpl.java:3265)
	at com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2243)
	at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2025)
	at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:778)
	at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:47)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
	at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:386)
	at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:330)
	at com.mysql.jdbc.jdbc2.optional.MysqlDataSource.getConnection(MysqlDataSource.java:428)
	at com.mysql.jdbc.jdbc2.optional.MysqlDataSource.getConnection(MysqlDataSource.java:136)
	at com.mysql.jdbc.jdbc2.optional.MysqlDataSource.getConnection(MysqlDataSource.java:107)

My preferred solution has been to use default-time-zone option to "configure the server" as instructed, but this solution is currently not workable when running MySQL via Docker, due to this issue / #543.

[BearKid]

TZ does not suport '+8:00'，any other solution ?
When I run MySQL with TZ=Asia/Shanghai, it starts with the following variables:

Varibale_name	Value
system_time_zone	CST
time_zone	SYSTEM

"CST" is a ambiguous time zone name，mysql jdbc driver would make mistakes if actual time zone of application servers is GMT+8