Timezone support

[t-ae]

Currently it seems Date is encoded/decoded as GMT+00:00.
encode/decode
Now I want to store date as local time zone. So I want to make the TimeZones above configurable.

There are two way to accomplish this.

1. Set TimeZone via MySQLDatabaseConfig
2. Get database's time zone while MySQLConnection.authenticate and use it

Eitherway we must provide time zone to convertFromMySQLTime and convertToMySQLTime.
Any ideas?

[tanner0101]

IMO this should be done at a higher level But I'd be interested to see the argument for including in this package. Do other low-level MySQL libraries do this?

[t-ae]

This library handles time zone.
This approach is like option 1 in the other issue and we encounter the QueryBuilder.filter problem.

[tanner0101]

I'd be interested to know how libmysql is getting the timezone information (that's what the library you linked is using).

MySQL gives back a MYSQL_TIME struct which is formatted as shown above. As you can see, no timezone information is supplied as a part of that struct. Perhaps it's sent somewhere else in the binary return data or there is some sort of flag to opt-in to retrieving it?

[tanner0101]

Ah, after looking into this more I see that MySQL is not capable of storing time zones alongside the data (PostgreSQL is, which is what confused me). The server has a global time zone and that is it.

I also looked into novi/mysql-swift more and it seems like they are not actually fetching the MySQL Server's time zone. You set the time zone when you create a connection, and all Date's created thereafter will use that timezone.

I think to add proper timezone support in this package, MySQLConnection should gain a new property timeZone: TimeZone? and a new method determineTimeZone() -> Future<Void>. This method would ask the server for its time zone, and set that time zone on the connection. You could also set the property manually.

Once set, all Dates retrieved from MySQL would have the appropriate time zone set. This should not affect dates sent to MySQL as I believe they are sent as UTC anyway (but that should be looked into as well).

[gwynne]

Closing this out as not relevant at this point.