Existe uma maneira no SQL Server 2012 de obter qual seria o fuso horário do servidor em uma determinada data/hora? No SQL Server 2016, você tem AT TIME ZONE, mas isso não está disponível em 2012. Eu tenho um datetimeoffsete preciso convertê-lo para o fuso horário do servidor (nessa data) antes de truncá-lo para datetime. SWITCHOFFSETsó funciona se você souber o deslocamento, mas para servidores que alteram seu fuso horário duas vezes ao ano, o deslocamento alternará para frente e para trás.
Esta consulta ilustra o recurso em ação no SQL Server 2016:
SELECT @@SERVERNAME AS [SERVERNAME]
, GETDATE() AT TIME ZONE 'Central Standard Time' AS [GETDATE() AT TIME ZONE 'Central Standard Time']
, GETDATE() AT TIME ZONE 'Eastern Standard Time' AS [GETDATE() AT TIME ZONE 'Eastern Standard Time']
, DATEADD(MONTH, -6, GETDATE()) AT TIME ZONE 'Central Standard Time' AS [DATEADD(MONTH, -6, GETDATE()) AT TIME ZONE 'Central Standard Time']
, DATEADD(MONTH, -6, GETDATE()) AT TIME ZONE 'Eastern Standard Time' AS [DATEADD(MONTH, -6, GETDATE()) AT TIME ZONE 'Eastern Standard Time']
;
Em junho, pelo menos, os tzoffsets nas duas primeiras colunas diferem das duas últimas colunas porque esse fuso horário "padrão" tem um deslocamento diferente em dezembro do que em junho.
Este é um ótimo caso de uso para uma tabela de calendário.
Aaron Bertrand cobre este cenário exato em profundidade aqui . O artigo inteiro é bastante profundo para replicar em uma resposta aqui, mas tentarei resumir.
Em essência, você cria uma tabela de datas e inclui nos metadados o início/fim do horário de verão para todos os anos com os quais está preocupado. Em seguida, você pode usar essas datas para converter a hora do seu fuso horário para UTC ou vice-versa. Depois de ter uma tabela de calendário para ingressar, de repente se torna trivial determinar se você está no horário padrão ou de verão sem precisar pular etapas.
No seu caso de uso, você pode converter para UTC trivialmente por meio do deslocamento e, em seguida, usar a abordagem da tabela de calendário de Aaron e a função de acompanhamento para converter de volta para a hora local.
Por uma questão de estilo, também sou um grande fã de sempre armazenar valores de data e hora em UTC para armazenamento de dados canônicos. Essas conversas de fuso horário e horário de verão são complicadas o suficiente para que, se você sempre armazenar os dados em UTC, você tenha bons dados e só tenha que lutar com bugs de exibição. Se você tiver um bug na forma como armazenou os dados, corrigi-lo exige a correção retroativa dos dados, o que é muito mais complexo.