1/3
go usa o banco de dados de fuso horário
da IANA com nomes de zona precisos. Tentando fazer engenharia reversa de como o MySQL determina o formato de fuso horário local de um host (Linux) e duplicar essa lógica em um go clientes - como @MattJohnson apontou - prova não ser confiável. 2/3
database/sql.DB - criado via Open(drv, DSN) - usará o mesmo DSN para todas as conexões. Enquanto um sql.DB deve ser criado uma vez e usado muitas vezes - não há como alterar o DSN após o fato - então seria necessário criar um novo sql.DB ao alterar o DSN . 3/3
Portanto, a melhor abordagem parece alavancar o
MySQL para converter todos os datetime valores do fuso horário local para UTC antes da transmissão para o cliente. Isso elimina a complicação de definir o fuso horário do banco de dados (possivelmente desconhecido) no momento da conexão por meio do DSN . Uma opção promissora é definir o fuso horário da sessão da conexão:
SET @@session.time_zone = "+00:00";- no entanto, isso só funciona para o atual conexão (dentro do pool de conexões). Um
goo cliente, no entanto, não saberá qual conexão gratuita ele pode estar usando a qualquer momento. - Para garantir que isso sempre funcione, seria necessário aplicá-lo manualmente antes de todas as consultas . Mesmo se apenas uma conexão de banco de dados estiver em uso - se a conexão falhar e a nova tentativa de conexão for iniciada - qualquer estado de sessão anterior será perdido.
Então, em vez disso, agrupar todos os
datatime colunas com uma função de conversão assim:CONVERT_TZ(`STAMP_UPDATED`,@@session.time_zone,'+00:00')
garante que o cálculo do fuso horário seja feito no momento da consulta e não seja perdido durante uma reconexão de conexão etc.
Então agora o
DSN não precisa mais especificar loc - como UTC é o padrão. Na verdade, o DSN só precisa da opção de sufixo ?parseTime=true para permitir o datetime para ser traduzido para go nativo de time.Time . Finalmente e mais importante, isso funcionará com qualquer servidor definido para qualquer fuso horário.
H/T para esta resposta .
