datetime - verao - timezoneinfo




Práticas recomendadas de horário de verão e fuso horário (20)

DateTimeZone::listAbbreviations()Saída do PHP

Esse método PHP retorna um array associativo contendo alguns fusos horários 'principais' (como o CEST), que por si só contêm fusos horários 'geográficos' mais específicos (como Europa / Amsterdã).

Se você estiver usando esses fusos horários e suas informações de deslocamento / DST, é extremamente importante perceber o seguinte:

Parece que todas as diferentes configurações offset / DST (incluindo configurações históricas) de cada fuso horário estão incluídas!

Por exemplo, a Europa / Amsterdã pode ser encontrada seis vezes na saída desta função. Duas ocorrências (offset 1172/4772) são para o tempo de Amsterdã usado até 1937; dois (1200/4800) são para o tempo que foi usado entre 1937 e 1940; e dois (3600/4800) são para o tempo usado desde 1940.

Portanto, você não pode confiar nas informações offset / DST retornadas por esta função como estando atualmente corretas / em uso!

Se você quiser saber o atual offset / DST de um determinado fuso horário, terá que fazer algo assim:

<?php
$now = new DateTime(null, new DateTimeZone('Europe/Amsterdam'));
echo $now->getOffset();
?>

Eu estou esperando fazer esta pergunta e as respostas a ela o guia definitivo para lidar com o horário de verão, em particular para lidar com as mudanças reais.

Se você tem alguma coisa para adicionar, por favor faça

Muitos sistemas dependem de manter o tempo exato, o problema é com as mudanças no tempo devido ao horário de verão - movendo o relógio para frente ou para trás.

Por exemplo, há regras de negócios em um sistema de ordens que dependem do tempo do pedido - se o relógio mudar, as regras podem não ser tão claras. Como deve o tempo do pedido ser persistido? Há, claro, um número infinito de cenários - este é simplesmente um exemplo ilustrativo.

  • Como você lidou com o problema de horário de verão?
  • Quais suposições fazem parte da sua solução? (procurando contexto aqui)

Tão importante, se não mais:

  • O que você tentou que não funcionou?
  • Por que isso não funcionou?

Eu estaria interessado em programação, OS, persistência de dados e outros aspectos pertinentes da questão.

As respostas gerais são ótimas, mas também gostaria de ver os detalhes, especialmente se estiverem disponíveis apenas em uma plataforma.


Resumo das respostas e outros dados: (por favor adicione o seu)

Faz:

  • Sempre que você estiver se referindo a um momento exato no tempo, persista o tempo de acordo com um padrão unificado que não seja afetado pela economia de horário de verão. (GMT e UTC são equivalentes a este respeito, mas é preferível usar o termo UTC. Observe que o UTC também é conhecido como Zulu ou Z time.)
  • Se, em vez disso, você optar por persistir um horário usando um valor de hora local, inclua o deslocamento da hora local para esse horário específico a partir do UTC (esse deslocamento pode mudar ao longo do ano), de modo que o registro de data e hora possa ser interpretado sem ambiguidade posteriormente.
  • Em alguns casos, pode ser necessário armazenar a hora UTC e a hora local equivalente. Geralmente isso é feito com dois campos separados, mas algumas plataformas suportam um tipo datetimeoffset que pode armazenar ambos em um único campo.
  • Ao armazenar registros de data e hora como um valor numérico, use o tempo Unix - que é o número de segundos inteiros desde 1970-01-01T00:00:00Z (excluindo os segundos bissextos). Se você precisar de maior precisão, use milissegundos. Esse valor deve sempre ser baseado em UTC, sem nenhum ajuste de fuso horário.
  • Se mais tarde você precisar modificar o registro de data e hora, inclua o ID do fuso horário original para determinar se o deslocamento pode ter sido alterado em relação ao valor original registrado.
  • Ao agendar eventos futuros, geralmente a hora local é preferida em vez de UTC, pois é comum que o deslocamento seja alterado. Veja resposta e postagem no blog .
  • Ao armazenar datas inteiras, como aniversários e aniversários, não converta para UTC ou qualquer outro fuso horário.
    • Quando possível, armazene em um tipo de dados somente de datas que não inclua uma hora do dia.
    • Se esse tipo não estiver disponível, sempre ignore a hora do dia ao interpretar o valor. Se não puder ter certeza de que a hora do dia será ignorada, escolha 12:00 noon, em vez de 00:00 Midnight como um horário representativo mais seguro naquele dia.
  • Lembre-se de que as compensações de fuso horário nem sempre são um número inteiro de horas (por exemplo, o Horário padrão indiano é UTC + 05: 30 e o Nepal usa o UTC + 05: 45).
  • Se estiver usando Java, use java.time para Java 8 ou use o Joda Time para Java 7 ou inferior.
  • Se estiver usando o .NET , considere usar o Noda Time .
  • Se estiver usando o .NET sem o Noda Time, considere que DateTimeOffset é geralmente uma escolha melhor que o DateTime .
  • Se estiver usando Perl, use DateTime .
  • Se estiver usando Python, use pytz ou dateutil .
  • Se estiver usando JavaScript, use moment.js com a extensão de moment-timezone .
  • Se estiver usando PHP> 5.2, use as conversões de fuso horário nativas fornecidas pelas classes DateTimeZone e DateTimeZone . Tenha cuidado ao usar DateTimeZone::listAbbreviations() - consulte a resposta . Para manter o PHP atualizado com os dados do Olson, instale periodicamente o pacote timezonedb PECL; veja a resposta .
  • Se estiver usando o C ++, certifique-se de usar uma biblioteca que use o implemento adequado do banco de dados de fuso horário da IANA . Isso inclui a biblioteca "tz" de cctz , ICU e Howard Hinnant .
    • Não use o Boost para conversões de fuso horário. Embora sua API alega suportar identificadores padrão da IANA (aka "zoneinfo"), mapeia-os grosseiramente para dados no estilo POSIX, sem considerar o rico histórico de alterações que cada zona pode ter. (Além disso, o arquivo ficou sem manutenção.)
  • Se estiver usando Rust, use o chrono .
  • A maioria das regras de negócios usa tempo civil, em vez de UTC ou GMT. Portanto, planeje converter registros de data e hora UTC em um fuso horário local antes de aplicar a lógica do aplicativo.
  • Lembre-se de que os fusos horários e os deslocamentos não são fixos e podem mudar. Por exemplo, historicamente, os EUA e o Reino Unido usaram as mesmas datas para "avançar" e "retroceder". No entanto, em 2007, os EUA alteraram as datas em que os relógios são alterados. Isto significa agora que durante 48 semanas do ano a diferença entre a hora de Londres e Nova Iorque é de 5 horas e durante 4 semanas (3 na primavera, 1 no outono) é de 4 horas. Esteja ciente de itens como este em quaisquer cálculos que envolvam várias zonas.
  • Considere o tipo de tempo (tempo real do evento, tempo de transmissão, tempo relativo, histórico, tempo recorrente) que elementos (registro de data e hora, fuso horário e nome do fuso horário) você precisa armazenar para recuperação correta - consulte "Tipos de horário". esta resposta .
  • Mantenha seus arquivos tzdata OS, banco de dados e aplicativos em sincronia entre si e o resto do mundo.
  • Nos servidores, defina os relógios de hardware e os relógios do sistema operacional como UTC, em vez de um fuso horário local.
  • Independentemente do ponto de marcador anterior, o código do lado do servidor, incluindo sites da Web, nunca deve esperar que o fuso horário local do servidor seja qualquer coisa em particular. veja a resposta .
  • Prefira trabalhar com fusos horários caso a caso no código do aplicativo, em vez de globalmente por meio de configurações ou padrões do arquivo de configuração.
  • Use serviços NTP em todos os servidores.
  • Se estiver usando FAT32 , lembre-se de que os timestamps são armazenados no horário local, não no UTC.
  • Ao lidar com eventos recorrentes (programa de TV semanal, por exemplo), lembre-se de que a hora muda com o horário de verão e será diferente nos fusos horários.
  • Sempre consulta os valores de data e hora como exclusivos de limite superior inclusivo e de limite inferior ( >= , < ).

Não faça:

  • Não confunda um "fuso horário", como America/New_York com um "deslocamento de fuso horário", como -05:00 . Eles são duas coisas diferentes. Veja o wiki da tag de fuso horário .
  • Não use o objeto Date do JavaScript para executar cálculos de data e hora em navegadores da Web mais antigos, pois o ECMAScript 5.1 e inferior possui uma falha de design que pode usar o horário de verão incorretamente. (Isso foi corrigido no ECMAScript 6/2015).
  • Nunca confie no relógio do cliente. Pode muito bem estar incorreto.
  • Não diga às pessoas para "sempre usarem o UTC em todos os lugares". Esse conselho difundido é míope de vários cenários válidos descritos anteriormente neste documento. Em vez disso, use a referência de tempo apropriada para os dados com os quais você está trabalhando. (O registro de data e hora pode usar o UTC, mas os valores futuros de agendamento de horário e data somente não devem.)

Teste:

  • Ao testar, certifique-se de testar países nos hemisférios ocidental, oriental, norte e Southern (na verdade, em cada quarto do globo, portanto, 4 regiões), com o DST em andamento e não (dá 8) e um país que não não use DST (outros 4 para cobrir todas as regiões, totalizando 12 no total).
  • Teste a transição do horário de verão, ou seja, quando você estiver no horário de verão, selecione um valor de horário no inverno.
  • Testar casos de limite, como um fuso horário que seja UTC + 12, com o horário de verão, tornando a hora local UTC + 13 no verão e até lugares que sejam UTC + 13 no inverno
  • Teste todas as bibliotecas e aplicativos de terceiros e verifique se eles lidam corretamente com os dados de fuso horário.
  • Teste os fusos horários de meia hora, pelo menos.

Referência:

De outros:

  • Lobby seu representante para acabar com a abominação que é DST. Nós podemos sempre esperar ...
  • Lobby para o Horário Padrão da Terra

Em geral, inclua o deslocamento da hora local (incluindo o deslocamento do horário de verão) em registros de data e hora armazenados: O UTC sozinho não é suficiente para exibir posteriormente o registro de data e hora em seu fuso horário original (e horário de verão).

Tenha em mente que o deslocamento nem sempre é um número inteiro de horas (por exemplo, o horário padrão indiano é UTC + 05: 30).

Por exemplo, formatos adequados são uma tupla (tempo unix, offset em minutos) ou ISO 8601 .


Embora eu não tenha tentado, uma abordagem para ajustes de fuso horário que eu consideraria atraente seria a seguinte:

  1. Armazene tudo no UTC.

  2. Crie uma tabela TZOffsetscom três colunas: RegionClassId, StartDateTime e OffsetMinutes (int, em minutos).

Na tabela, armazene uma lista de datas e horas em que a hora local foi alterada e em quanto. O número de regiões na tabela e o número de datas dependerão de qual intervalo de datas e áreas do mundo você precisa suportar. Pense nisso como se fosse uma data "histórica", embora as datas devam incluir o futuro em algum limite prático.

Quando você precisar calcular a hora local de qualquer hora UTC, faça o seguinte:

SELECT DATEADD('m', SUM(OffsetMinutes), @inputdatetime) AS LocalDateTime
FROM   TZOffsets
WHERE  StartDateTime <= @inputdatetime
       AND RegionClassId = @RegionClassId;

Você pode querer armazenar em cache esta tabela em seu aplicativo e usar o LINQ ou alguns meios semelhantes para fazer as consultas, em vez de atingir o banco de dados.

Esses dados podem ser destilados do banco de dados tz de domínio público .

Vantagens e notas de rodapé desta abordagem:

  1. Nenhuma regra é inserida no código. Você pode ajustar os deslocamentos de novas regiões ou períodos rapidamente.
  2. Você não precisa suportar todos os intervalos de datas ou regiões, você pode adicioná-los conforme necessário.
  3. As regiões não precisam corresponder diretamente aos limites geopolíticos e, para evitar a duplicação de linhas (por exemplo, a maioria dos estados nos EUA manipula o DST da mesma forma), você pode ter entradas de RegionClass amplas que vinculam em outra tabela a listas mais tradicionais de estados, países, etc.
  4. Para situações como os EUA, onde a data de início e término do horário de verão mudou nos últimos anos, é muito fácil lidar com isso.
  5. Como o campo StartDateTime também pode armazenar um horário, o tempo de alteração padrão das 2:00 AM é tratado facilmente.
  6. Nem todos os lugares do mundo usam um horário de verão de 1 hora. Isso lida com esses casos facilmente.
  7. A tabela de dados é multi-plataforma e pode ser um projeto de código aberto separado que pode ser usado por desenvolvedores que usam praticamente qualquer plataforma de banco de dados ou linguagem de programação.
  8. Isso pode ser usado para compensações que não têm nada a ver com fusos horários. Por exemplo, os ajustes de 1 segundo que acontecem de tempos em tempos para ajustar a rotação da Terra, os ajustes históricos e dentro do calendário gregoriano, etc.
  9. Como isso está em uma tabela de banco de dados, as consultas de relatório padrão, etc., podem aproveitar os dados sem uma falha no código de lógica de negócios.
  10. Isso também lida com deslocamentos de fuso horário, se você quiser, e pode até mesmo contar casos históricos especiais em que uma região é atribuída a outro fuso horário. Tudo o que você precisa é de uma data inicial que atribua um deslocamento de fuso horário a cada região com uma data de início mínima. Isso exigiria a criação de pelo menos uma região para cada fuso horário, mas permitiria que você fizesse perguntas interessantes como: "Qual é a diferença no horário local entre Yuma, Arizona e Seattle, Washington em 2 de fevereiro de 1989 às 5:00?" (Basta subtrair um SUM () do outro).

Agora, a única desvantagem dessa abordagem ou de qualquer outra é que as conversões do horário local para o GMT não são perfeitas, já que qualquer alteração do horário de verão que tenha um deslocamento negativo para o relógio repete um determinado horário local. Não há maneira fácil de lidar com isso, receio, que é uma razão pela qual armazenar os horários locais é uma má notícia em primeiro lugar.


Faça uma separação arquitetural clara das preocupações - para saber exatamente qual camada interage com os usuários e tem que alterar a data / hora para / da representação canônica (UTC). A data / hora não UTC é a apresentação (segue o fuso horário local do usuário), a hora UTC é o modelo (permanece exclusiva para as camadas back-end e mid).

Além disso, decida qual é o seu público real, o que você não precisa servir e onde você desenha a linha . Não toque em calendários exóticos, a menos que você tenha clientes importantes e, em seguida, considere servidores separados voltados para o usuário apenas para essa região.

Se você puder adquirir e manter a localização do usuário, use o local para conversão sistemática de data e hora (digamos, cultura .NET ou uma tabela SQL), mas forneça uma maneira de o usuário final escolher substituições se a data-hora for crítica para seus usuários.

Se houver obrigações históricas de auditoria envolvidas (como dizer exatamente quando Jo in AZ pagou uma fatura 2 anos atrás em setembro) , mantenha o UTC e a hora local para o registro (suas tabelas de conversão serão alteradas ao longo do tempo).

Defina o fuso horário de referência para dados que vêm em massa - como arquivos, serviços da Web, etc. Diga que a empresa da East Coast tem data center na CA - você precisa perguntar e saber o que eles usam como padrão em vez de assumir um ou outro.

Não confie as compensações de fuso horário incorporadas na representação textual da data e hora e não aceite que as analise e as siga. Em vez disso, sempre solicite que o fuso horário e / ou a zona de referência tenham que ser explicitamente definidos . Você pode facilmente receber o tempo com o deslocamento PST, mas o tempo é realmente EST, pois esse é o tempo de referência do cliente e os registros foram exportados apenas em um servidor que está em PST.


Não tenho certeza do que posso acrescentar às respostas acima, mas aqui estão alguns pontos meus:

Tipos de vezes

Existem quatro momentos diferentes que você deve considerar:

  1. Hora do evento: por exemplo, a hora em que um evento esportivo internacional acontece, ou uma coroação / morte / etc. Isso depende do fuso horário do evento e não do visualizador.
  2. Tempo de televisão: por exemplo, um determinado programa de TV é transmitido às 9h, horário local, em todo o mundo. Importante quando pensar em publicar os resultados (de, digamos, American Idol) em seu site
  3. Tempo relativo: por exemplo: Esta questão tem uma recompensa aberta em 21 horas. Isso é fácil de exibir
  4. Tempo recorrente: por exemplo: um programa de TV é exibido todas as segundas-feiras às 21h, mesmo quando o horário de verão é alterado.

Há também histórico / tempo alternativo. Estes são irritantes porque podem não mapear de volta ao tempo padrão. Por exemplo: datas julianas, datas de acordo com um calendário lunar em Saturno, o calendário klingon.

Armazenar timestamps de início / fim no UTC funciona bem. Para 1, você precisa de um nome de fuso horário do evento + deslocamento armazenado junto com o evento. Para 2, você precisa de um identificador de hora local armazenado com cada região e um nome de fuso horário local + deslocamento armazenado para cada visualizador (é possível derivar isso do IP se você estiver em uma crise). Para 3, armazene em UTC segundos e não há necessidade de fusos horários. 4 é um caso especial de 1 ou 2, dependendo se for um evento global ou local, mas também é necessário armazenar um criado no registro de data e hora para que você possa identificar se uma definição de fuso horário foi alterada antes ou depois da criação desse evento. Isso é necessário se você precisar mostrar dados históricos.

Tempos de armazenamento

  • Sempre armazene tempo em UTC
  • Converte para a hora local no display (local sendo definido pelo usuário olhando para os dados)
  • Ao armazenar um fuso horário, você precisa do nome, do registro de data e hora e do deslocamento. Isso é necessário porque os governos às vezes alteram os significados de seus fusos horários (por exemplo: o governo dos EUA alterou as datas do DST) e seu aplicativo precisa lidar com as coisas normalmente ... por exemplo: O registro de data e hora exato quando os episódios de LOST mostravam regras DST antes e depois mudou.

Compensações e nomes

Um exemplo do acima seria:

O jogo das finais da copa do mundo de futebol aconteceu na África do Sul (UTC + 2 - SAST) em 11 de julho de 2010 às 19:00 UTC.

Com essas informações, podemos determinar historicamente a hora exata em que as finais do WCS 2010 ocorreram, mesmo que a definição do fuso horário da África do Sul mude, e exibir isso para os espectadores no fuso horário local no momento em que consultam o banco de dados.

Hora do sistema

Você também precisa manter seus arquivos tzdata de SO, banco de dados e aplicativo em sincronia, entre si e com o resto do mundo, e fazer testes extensivos ao atualizar. Não é inédito que um aplicativo de terceiros do qual você depende não tenha manipulado uma alteração de TZ corretamente.

Certifique-se de que os relógios de hardware estejam configurados como UTC e, se você estiver executando servidores em todo o mundo, verifique se os sistemas operacionais estão configurados para usar o UTC também. Isso se torna aparente quando você precisa copiar arquivos de log apache girados de hora em hora de servidores em vários fusos horários. Classificá-los por nome de arquivo só funciona se todos os arquivos forem nomeados com o mesmo fuso horário. Isso também significa que você não precisa fazer a matemática do dia na sua cabeça quando você vai de uma caixa para outra e precisa comparar os timestamps.

Além disso, execute o ntpd em todas as caixas.

Clientes

Nunca confie no timestamp que você obtém de uma máquina cliente como válido. Por exemplo, os cabeçalhos Date: HTTP ou uma chamada Date.getTime() javascript. Eles são bons quando usados ​​como identificadores opacos, ou quando fazem cálculos de data durante uma única sessão no mesmo cliente, mas não tentem fazer referência cruzada a esses valores com algo que você tenha no servidor. Seus clientes não executam NTP e podem não ter necessariamente uma bateria funcionando para o seu relógio BIOS.

Trivialidades

Finalmente, os governos às vezes fazem coisas muito estranhas:

A hora padrão na Holanda foi exatamente 19 minutos e 32,13 segundos à frente da UTC por lei de 1909-05-01 a 1937-06-30. Este fuso horário não pode ser representado exatamente usando o formato HH: MM.

Ok, acho que terminei.


Se o seu design puder acomodá-lo, evite a conversão da hora local todos juntos!

Eu sei que para alguns isso pode soar insano, mas pense em UX: os usuários processam datas próximas (hoje, ontem, segunda-feira seguinte) mais rapidamente do que as datas absolutas (2010.09.17, sexta-feira, 17 de setembro) no relance. E quando você pensa mais sobre isso, a precisão dos fusos horários (e DST) é mais importante quanto mais próxima a data estiver now() , portanto, se você puder expressar datas / datas em um formato relativo de +/- 1 ou 2 semanas, o resto das datas pode ser UTC e não importa muito para 95% dos usuários.

Dessa forma, você pode armazenar todas as datas em UTC e fazer as comparações relativas em UTC e simplesmente mostrar as datas UTC do usuário fora do seu Limite de data relativa.

Isso também pode se aplicar à entrada do usuário (mas geralmente de maneira mais limitada). Selecionar em um menu suspenso que tenha apenas {Ontem, Hoje, Amanhã, Próxima segunda, Próxima quinta-feira} é muito mais simples e fácil para o usuário do que um seletor de datas. Os selecionadores de data são alguns dos componentes que mais induzem a dor no preenchimento de formulários. É claro que isso não funcionará para todos os casos, mas você pode ver que basta um design um pouco inteligente para torná-lo muito poderoso.


Você precisa saber sobre o banco de dados Olson tz , que está disponível em ftp://elsie.nci.nih.gov/pub http://iana.org/time-zones/ . Ele é atualizado várias vezes por ano para lidar com as mudanças frequentes de última hora em quando (e se) alternar entre o inverno e o verão (padrão e horário de verão) em diferentes países do mundo. Em 2009, o último lançamento foi em 2009; em 2010, foi 2010n; em 2011, foi 2011n; no final de maio de 2012, o lançamento foi 2012c. Observe que há um conjunto de códigos para gerenciar os dados e os próprios dados do fuso horário, em dois arquivos separados (tzcode20xxy.tar.gz e tzdata20xxy.tar.gz). Tanto o código como os dados estão no domínio público.

Esta é a fonte de nomes de fuso horário, como America / Los_Angeles (e sinônimos como US / Pacific).

Se você precisar controlar diferentes zonas, precisará do banco de dados Olson. Como outros aconselham, você também deseja armazenar os dados em um formato fixo - UTC é normalmente o escolhido - junto com um registro do fuso horário no qual os dados foram gerados. Você pode querer distinguir entre o deslocamento de UTC no momento e o nome do fuso horário; isso pode fazer a diferença depois. Além disso, sabendo que é atualmente 2010-03-28T23: 47: 00-07: 00 (EUA / Pacífico) pode ou não pode ajudá-lo a interpretar o valor 2010-11-15T12: 30 - que é presumivelmente especificado em PST ( Hora Padrão do Pacífico) em vez de PDT (Horário de Verão do Pacífico).

As interfaces padrão da biblioteca C não são muito úteis com esse tipo de coisa.

Os dados de Olson mudaram, em parte porque AD Olson irá se aposentar em breve, e em parte porque houve um processo (agora descartado) contra os mantenedores por violação de direitos autorais. O banco de dados de fuso horário agora é gerenciado sob os auspícios da IANA , a Internet Assigned Numbers Authority, e há um link na primeira página para o 'Banco de Dados do Fuso Horário' . A lista de discussão é agora [email protected] ; a lista de anúncios é [email protected] .


Aqui está a minha experiência: -

(Não requer nenhuma biblioteca de terceiros)

  • No lado do servidor, armazene os tempos no formato UTC para que todos os valores de data / hora no banco de dados estejam em um único padrão, independentemente da localização de usuários, servidores, fusos horários ou horário de verão.
  • Na camada da interface do usuário ou nos emails enviados para o usuário, você precisa mostrar os horários de acordo com o usuário. Nesse caso, você precisa ter o deslocamento do fuso horário do usuário para poder adicionar esse deslocamento ao valor UTC do seu banco de dados, o que resultará na hora local do usuário. Você pode usar o deslocamento do fuso horário do usuário quando estiver se inscrevendo ou detectá-lo automaticamente nas plataformas da Web e móvel. Para sites, o método getTimezoneOffset () da função JavaScript é um padrão desde a versão 1.0 e compatível com todos os navegadores. (Ref: http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp )

Eu bati isso em dois tipos de sistemas, "sistemas de planejamento de turno (por exemplo, trabalhadores de fábrica)" e "sistemas de gerenciamento de dependência de gás" ...

23 e 25 horas longos dias são uma dor para lidar com isso, são 8h turnos que levam 7h ou 9h. O problema é que você descobrirá que cada cliente, ou mesmo o departamento do cliente, tem regras diferentes que criaram (geralmente sem documentar) sobre o que fazem nesses casos especiais.

Algumas perguntas não são mais solicitadas ao cliente até que ele pague pelo software "pronto para uso". É muito raro encontrar um cliente que pense sobre esse tipo de problema na hora de comprar um software.

Eu acho que em todos os casos você deve registrar o tempo no UTC e converter de / para a hora local antes de armazenar a data / hora. No entanto, mesmo sabendo que tomar um determinado tempo está em pode ser difícil com o horário de verão e fusos horários.


Nunca confie apenas em construtores como

 new DateTime(int year, int month, int day, int hour, int minute, TimeZone timezone)

Eles podem lançar exceções quando uma determinada data não existe devido ao horário de verão. Em vez disso, crie seus próprios métodos para criar essas datas. Neles, capture qualquer exceção que ocorra devido ao horário de verão e ajuste o tempo necessário com o deslocamento de transição. O horário de verão pode ocorrer em datas diferentes e em horários diferentes (mesmo à meia-noite do Brasil), de acordo com o fuso horário.


Para a web, as regras não são tão complicadas ...

  • Do lado do servidor, use o UTC
  • Do lado do cliente, use Olson
    • Motivo: os deslocamentos UTC não são seguros para horário de verão (por exemplo, Nova York é EST (UTC - 5 horas), parte do ano, EDT (UTC - 4 horas) restante do ano).
    • Para determinação do fuso horário no lado do cliente, você tem duas opções:

O resto é apenas conversão UTC / local usando as bibliotecas datetime do lado do servidor. Bom para ir...


Só queria apontar duas coisas que parecem imprecisas ou pelo menos confusas:

Sempre persista o tempo de acordo com um padrão unificado que não seja afetado pela economia de horário de verão. O GMT e o UTC foram mencionados por pessoas diferentes, embora o UTC pareça ser mencionado com mais frequência.

Para (quase) todas as finalidades práticas de computação, a UTC é, de fato, GMT. A menos que você veja um timestamps com um segundo fracionário, você está lidando com o GMT, o que torna essa distinção redundante.

Inclua o deslocamento da hora local como está (incluindo o deslocamento DST) ao armazenar registros de data e hora.

Um registro de data e hora é sempre representado em GMT e, portanto, não possui deslocamento.


Uma outra coisa, certifique-se de que os servidores tenham o patch de economia de horário atualizado aplicado.

Tivemos uma situação no ano passado em que nossos tempos estavam consistentemente fora de uma hora por um período de três semanas para usuários norte-americanos, apesar de estarmos usando um sistema baseado em UTC.

Acontece que no final foram os servidores. Eles só precisavam de um patch atualizado aplicado ( Windows Server 2003 ).


Apenas um exemplo para provar que o tempo de manuseio é a grande bagunça descrita e que você nunca pode ser complacente. Em vários pontos desta página, segundos-bissextos foram ignorados.

Vários anos atrás, o sistema operacional Android usava satélites GPS para obter uma referência de tempo UTC, mas ignorou o fato de que os satélites de GPS não usam saltos-segundos. Ninguém notou até que houve confusão na véspera de Ano Novo, quando os usuários de telefones da Apple e os usuários de telefones Android fizeram suas contagens com cerca de 15 segundos de intervalo.

Eu acho que já foi consertado, mas você nunca sabe quando esses pequenos detalhes voltarão para assombrá-lo.


As regras de negócios devem sempre funcionar no tempo civil (a menos que haja legislação que diga o contrário). Esteja ciente de que o tempo civil é uma bagunça, mas é o que as pessoas usam, então é o que é importante.

Internamente, mantenha os timestamps em algo como civil-time-seconds-from-epoch. A epoch não importa particularmente (eu sou a favor da época do Unix ), mas torna as coisas mais fáceis do que a alternativa. Finja que leap-seconds não existem, a menos que você esteja fazendo algo que realmente precise deles (por exemplo, rastreamento por satélite). O mapeamento entre os registros de data e hora e o horário exibido é o único ponto em que as regras de DST devem ser aplicadas; as regras mudam frequentemente (em um nível global, várias vezes ao ano; culpem os políticos), portanto, você deve certificar-se de não codificar o mapeamento. O banco de dados TZ de Olson é inestimável.


Para aqueles que lutam com isso no .NET , veja se usando DateTimeOffsete / ou TimeZoneInfovalem a pena.

Se você quiser usar os fusos horários IANA / Olson ou descobrir que os tipos internos são insuficientes para suas necessidades, confira o Noda Time , que oferece uma API de data e hora muito mais inteligente para o .NET.


Quando se trata de aplicativos que são executados em um servidor , incluindo sites da Web e outros serviços de back-end, a configuração de fuso horário do servidor deve ser ignorada pelo aplicativo.

O conselho comum é definir o fuso horário do servidor como UTC. Essa é realmente uma boa prática recomendada, mas está lá como um band-aid para aplicativos que não seguem outras práticas recomendadas. Por exemplo, um serviço pode estar gravando em arquivos de log com carimbos de data / hora locais em vez de carimbos de data / hora baseados em UTC, criando assim ambigüidades durante a transição de fallback de horário de verão. Definir o fuso horário do servidor como UTC consertará esse aplicativo. No entanto, a correção real seria para o aplicativo registrar usando o UTC para começar.

O código do lado do servidor, incluindo sites da Web, nunca deve esperar que o fuso horário local do servidor seja qualquer coisa em particular.

Em alguns idiomas, o fuso horário local pode ser facilmente inserido no código do aplicativo. Por exemplo, o DateTime.ToUniversalTimemétodo no .NET converterá do fuso horário local para UTC, e a DateTime.Nowpropriedade retornará a hora atual no fuso horário local. Além disso, o Dateconstrutor em JavaScript usa o fuso horário local do computador. Existem muitos outros exemplos como este. É importante praticar a programação defensiva, evitando qualquer código que use a configuração de fuso horário local do computador.

Reserve usando o fuso horário local para o código do lado do cliente, como aplicativos de área de trabalho, aplicativos móveis e JavaScript do lado do cliente.


Tenha cuidado ao lidar com registros de data e hora armazenados no sistema de arquivos FAT32 - ele é sempre persistido nas coordenadas de hora local (que incluem DST - consulte o artigo msdn ). Ficou queimado naquele.


Você está usando o framework .NET ? Se assim for, deixe-me apresentar-lhe o tipo DateTimeOffset , adicionado com o .NET 3.5.

Essa estrutura contém um DateTimee um deslocamento ( TimeSpan), que especifica a diferença entre a DateTimeOffsetdata e a hora da instância e o tempo universal coordenado (UTC).

  • O DateTimeOffset.Nowmétodo estático retornará uma DateTimeOffsetinstância que consiste no horário atual (local) e no deslocamento local (conforme definido nas informações regionais do sistema operacional).

  • O DateTimeOffset.UtcNowmétodo estático retornará uma DateTimeOffsetinstância que consiste no horário atual em UTC (como se você estivesse em Greenwich).

Outros tipos votos são os TimeZone e TimeZoneInfo classes.





datetimeoffset