Add optional time zone information for DATETIME database colums. #80
Conversation
MySQL DATETIME columns store times without information about the time zone the time should be interpreted in. This commit adds the posibility to specify which time zone is used for columns accessed via a mymysql database connection. If a timezone is specified, times are converted to the correct time zone before being sent to the database, and are interpreted as being in this time zone when returned from the database. If no time zone is set, all times are assumed to be in the current local time zone. There are two methods for specifying the time zone. The new global variable mysql.DefaultTimeZone can be set to set the timezone for all database connections opened afterwards. A per-connection time zone can be chosen by setting the new native.Conn.TimeZone field.
|
We ran into this issue as well (the application writing data to the database we are reading from is in UTC, but the driver reads it as time.Local); would it be possible to get this reviewed and merged in @ziutek ? |
|
Your timezone information is lost when your write data to the database (there is no any TZ info in MySQL). Another problem is that MySQL supports text queries, that can contain date. Such date can't be handled by any driver. There is no general solution for this problem, see: #77 The best way to reliably store date and time in MySQL database is store the Unix timestamp (see Time.Unix() function) and optionaly TZ info in separate column. Using MySQL DATETIME can always cause problems in special cases. |
|
I agree that a better solution is to write the dates as unix timestamps, but we are working against a legacy system's database where we cannot make such a change. The driver cannot inherently know the timezone the date fields are in, but I think a reasonable compromise is to be able to inform the driver what timezone to interpret the datetimes as (which is what this PR does). For example, we know that all of our datetime fields are UTC so it would be nice to be able to read them from the database as such and not need to make the conversion after the fact. I also feel like time.Local is a bad default because this can change depending on where the application is being ran. |
MySQL DATETIME columns store times without information about the time zone the time should be interpreted in. This commit adds the posibility to specify which time zone is used for columns accessed via a mymysql database connection. If a timezone is specified, times are converted to the correct time zone before being sent to the database, and are interpreted as being in this time zone when returned from the database. If no time zone is set, all times are assumed to be in the current local time zone.
There are two methods for specifying the time zone. The new global variable mysql.DefaultTimeZone can be set to set the timezone for all database connections opened afterwards. A per-connection time zone can be chosen by setting the new native.Conn.TimeZone field.