"Australia/Lord_Howe" é o fuso horário mais estranho

• Fusos horários são complicados, mas como os computadores precisam implementá-los, sua estranheza existe apenas dentro de um intervalo finito.
  • Asia/Kathmandu tem um deslocamento incomum em relação ao UTC.
  • Africa/Casablanca não se encaixa bem no modelo de fuso horário, então é tratado com hardcode.
  • America/Nuuk inicia o horário de verão a partir de -01:00.
  • Africa/Cairo e America/Santiago iniciam o horário de verão às 24h (e não à 0h).
  • Australia/Lord_Howe tem a regra de horário de verão mais estranha.

PGXIIREAM: o Papa Gregório XIII controla tudo

• A maior parte do mundo usa um sistema de tempo baseado no calendário gregoriano.
• O calendário gregoriano é muito útil para manter a posição do sol consistente ao longo do ano.
• UTC é a formulação oficial moderna do calendário gregoriano, e o mundo inteiro define o tempo com base nele.

Segundos bissextos não importam

• A rotação da Terra está desacelerando, e segundos bissextos são adicionados para compensar isso.
• Segundos bissextos podem ser ignorados porque linguagens de programação não representam 61 segundos.
• Provedores de nuvem resolvem o problema desacelerando seus relógios durante um segundo bissexto.

Fusos horários estranhos

Asia/Kathmandu tem um deslocamento incomum

• O Nepal está 5 horas e 45 minutos à frente do UTC.
• Os computadores conseguem saber disso por meio do banco de dados de fusos horários da IANA.

Strings como PDT ou CET não significam nada

• Identificadores de fuso horário podem ser ambíguos, e muitos fusos compartilham o mesmo identificador.

Como fusos horários com horário de verão são representados?

• As regras de transição do horário de verão são complexas, e os computadores calculam a hora local com base nelas.

Africa/Casablanca e Asia/Gaza seguem a lua, mas fusos horários seguem o sol

• Marrocos e Gaza ajustam o horário de verão de acordo com o Ramadã, e isso é tratado com hardcode.

America/Nuuk muda para o horário de verão à -1h

• A Groenlândia inicia o horário de verão no mesmo momento que a Europa, mas no horário local isso acontece à -1h.

America/Santiago e Africa/Cairo fazem a transição às 24h

• Esses fusos mudam para o horário de verão às 24h, o que significa passar para o dia seguinte.

Australia/Lord_Howe tem a transição de horário de verão mais estranha

• A Ilha Lord Howe tem uma transição de horário de verão de 30 minutos.

Resumo do GN⁺

• Fusos horários são complicados, mas como os computadores precisam implementá-los, sua estranheza existe apenas dentro de um intervalo finito.
• Australia/Lord_Howe é o fuso horário mais peculiar, com uma transição de horário de verão de 30 minutos.
• Este artigo é útil para entender a complexidade dos fusos horários e pode ser interessante para programadores.
• Um projeto com funcionalidade semelhante é o tzdb.

[GN⁺]

Opiniões do Hacker News

• A parte mais divertida do banco de dados tz é que ele inclui uma estimativa do momento do Big Bang e foi feito para não calcular transições de fuso horário que ocorram antes do Big Bang.
  A mensagem do commit em https://github.com/eggert/tz/commit/b22d459a367f4d01b10f6f6b... também dizia, em essência, “não vamos gerar timestamps anteriores ao Big Bang, pois eles são fisicamente duvidosos”, e logo depois outro commit separado proibiu também segundos intercalares anteriores ao Big Bang.

  • Antigamente havia uma longa página de manual sobre o significado de datas passadas no date do Linux/Unix.
    Ela trazia exemplos por volta do século XV e histórias do tipo: um rei gostava de certa semana/mês e mandou repeti-lo, ou outro rei não gostava de determinada semana e a removeu do calendário. Era uma leitura bastante reveladora, mas agora não consigo mais encontrá-la.
  • Parece uma decisão bastante prática. É uma boa forma de evitar de antemão discussões inúteis entre contribuidores, como debater quantos anjos cabem na ponta de um alfinete.
    Em outras palavras, a conclusão é: “momentos anteriores ao Big Bang estão fora do escopo desta biblioteca; portanto, se algum algoritmo só produz valores incorretos antes do Big Bang, esse algoritmo é aceitável e não precisa ser melhorado/substituído”.
  • É uma parte realmente incrível, mas, separadamente, sou um pouco cético quanto à tentativa do tzdb de lidar até com datas anteriores ao Unix epoch.
    A utilidade dessa parte não parece grande em relação aos bugs que ela pode causar, e a maior parte da complexidade bagunçada do tzdb está no zic. Às vezes sinto que teria sido melhor se o zic não fosse um artefato do qual outras pessoas pudessem depender.
  • É um easter egg interessante do banco de dados TZ. Nunca tinha ouvido falar, mas fico pensando com que frequência alguém precisa calcular dados de fuso horário tão antigos.
    Espero que os próprios fusos horários desapareçam antes que a teoria dos fusos horários fique obsoleta.

• Para mim, o fuso horário mais estranho é Africa/Addis_Ababa. O curioso é que os moradores da Etiópia não seguem esse sistema.
  Localmente, eles deslocam a hora em 6 horas: o ciclo AM começa ao amanhecer, isto é, às 6h, e o ciclo PM começa ao pôr do sol, às 18h.
  https://en.wikipedia.org/wiki/Time_in_Ethiopia

  • É um sistema comum em toda a África Oriental, incluindo o Quênia. A noite termina às 6h, e 7h vira a primeira hora do dia, saa moja.
    Da mesma forma, o dia termina às 18h, thenashara. Intuitivamente, faz muito mais sentido do que o relógio anglófono, e como isso está incorporado ao idioma, confusões de horário são raras.
  • A contagem do tempo na Etiópia é incomum de modo geral.
    https://en.wikipedia.org/wiki/Ethiopian_calendar
    O calendário etíope é composto por 12 meses de 30 dias e por 5 ou 6 dias epagômenos que formam o 13º mês.
  • É muito parecido com a forma como os romanos entendiam o tempo. Fico me perguntando se é um vestígio antigo da época em que o norte da África era formado por várias províncias.
    https://en.wikipedia.org/wiki/Roman_timekeeping
  • Para um país perto do equador, essa não é uma forma tão irracional de definir o ciclo do dia.
  • O Japão também usa algo parecido no contexto de estabelecimentos que fecham depois da meia-noite: https://en.wikipedia.org/wiki/Date_and_time_notation_in_Japa...
    O mundo anglófono também já teve uma época em que o ano mudava em 25 de março: https://en.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750#...
    Tecnicamente, nenhum dos dois é algo que o tzdb consiga tratar. O tzdb lida com tempo civil, não com calendários ou outros métodos de contagem.

• A estranheza de Asia/Jerusalem vem do fato de o horário de verão estar fortemente ligado à questão da separação entre religião e Estado. Pessoas religiosas querem que o dia de trabalho seja conveniente em relação aos feriados que começam ao pôr do sol.
  Por isso, durante décadas, até meados dos anos 2000, o horário de verão era resultado de negociações anuais entre partidos religiosos e seculares, e muitas vezes a decisão só saía pouco antes da mudança, causando problemas frequentes.
  Ainda existe uma exceção para impedir que o horário de verão termine em Rosh HaShanah, então acho que as regras futuras parecem complexas por causa disso.

  • Como os benefícios do horário de verão são limitados, especialmente para um país relativamente ao sul, fico me perguntando por que ele não foi abolido completamente.
    Se a UE acabar conseguindo aboli-lo, talvez sigam o mesmo caminho.
  • É por causa da Páscoa judaica. A grande refeição festiva chamada Seder continua até depois da meia-noite e é um evento muito importante também para as crianças.
    Por isso, não querem que o horário de verão deixe ainda mais tarde um evento que já termina tarde. Além disso, no dia de jejum de Yom Kippur, queriam que o jejum terminasse 1 hora mais cedo. Tentar ajustar tudo a essas datas acabava deixando o período de horário de verão curto demais, então era preciso negociar.
  • Não há mais exceções. O IDT foi estendido em 2013 até o último domingo de outubro.

• A afirmação de que “linguagens de programação não conseguem representar um minuto de 61 segundos” não é verdadeira. Alguém já comentou que Raku dá suporte a segundos intercalares, e isso pode ser parcialmente culpa minha
  Isso porque DateTime.pm, a biblioteca de data/hora mais popular do Perl 5, dá suporte a segundos intercalares, e fui eu que implementei esse suporte ao criar o DateTime.pm
  Olhando para trás, quase certamente foi um erro. Quase ninguém se importa com segundos intercalares, e isso só cria confusões estranhas como “por que somar 60 segundos às vezes é diferente de somar 1 minuto?”
  Em especial, como tentei validar se second => 60 era válido, o código ficou muito mais complexo. O construtor recebe componentes de tempo e um fuso horário arbitrário; então, para consultar a tabela de segundos intercalares, é preciso converter para UTC, mas essa própria conversão, por motivos históricos, acaba se enroscando com valores que incluem segundos intercalares
  Virou uma bagunça enorme para um ganho minúsculo, e, como a biblioteca padrão de data/hora do Raku parece ter tomado bastante coisa emprestada do DateTime.pm do Perl 5, acho que ela herdou algumas das mesmas decisões ruins de design

  • É bom que tenha sido implementado assim e que depois tenha sido possível olhar para uma solução mais elegante
    Fico curioso sobre qual foi o processo mental inicial. Você estava mergulhado demais no problema? Quando se está perto demais de um problema e concentrado nele por tempo demais, às vezes o prazer de consertá-lo antes que ele quebre leva a esse tipo de coisa
  • Raku tem a classe Instant
    Ela é definida mais ou menos assim: “Instant é um momento específico medido em segundos atômicos e sua parte fracionária, e não está vinculado nem é aware de nenhuma epoch”

• No começo deste ano, precisei escrever uma função que encontrasse a hora local atual a partir de um endereço dos EUA. A abordagem ingênua seria mapear estaticamente o estado para um fuso horário, mas há várias exceções que impedem isso
  Naquela aplicação, custo e velocidade eram importantes, então comprei por alguns dólares um CSV que mapeava todos os ZIP codes dos EUA para offset UTC, observância de horário de verão etc.
  Como pytz recebe nomes de fusos horários da IANA, acabei tendo que mapear manualmente as informações de offset e horário de verão para fusos específicos, e, por causa dos territórios ultramarinos dos EUA e bases militares, também precisei de semânticas estranhas como as dos fusos Etc
  [1] https://en.wikipedia.org/wiki/Tz_database#Area

  • O nível de estado tem uma resolução completamente errada. Os fusos horários dos EUA seguem limites de condados e de reservas indígenas
    ZIP code provavelmente pode ser suficiente, mas é preciso tomar cuidado. Se a quantidade de endereços não for grande demais, uma abordagem mais robusta é fazer geocodificação reversa e então usar uma biblioteca que obtenha o identificador IANA a partir dos polígonos de fronteira dos fusos horários
    https://github.com/RomanIakovlev/timeshape é mantida por um ex-colega, e conseguimos abrir como código aberto parte do trabalho que fazíamos internamente
  • Em 1985, quando eu era um jovem engenheiro recém-formado na faculdade, fui encarregado de combinar dados de telemetria gravados em fita magnética em vários sites de radar dos EUA
    Um ou dois sistemas carimbavam os dados em hora local, e os demais usavam UTC. Comprei um antigo Farmers' Almanac para tentar criar um algoritmo que tratasse o horário de verão, mas me desesperei ao ler as regras
    O calendário trazia as regras nominais de transição, mas havia uma nota de rodapé dizendo que, por causa de intervenções do Congresso, elas vinham sendo ajustadas ano a ano e continuariam sendo. Eu disse ao meu chefe: “se eu conseguisse escrever um algoritmo para prever futuras votações do Congresso, eu seria bilionário e largaria este trabalho de engenharia”
    No fim, acho que codifiquei as transições conhecidas mais recentes e as regras nominais futuras. Era antes de todo mundo estar conectado à rede, e o código rodava em computadores independentes como VAX, então não havia muitas outras opções
    Combinar três fontes de dados de rastreamento, cada uma com seu próprio estado de validade e de degradação da qualidade de medição, também era um pesadelo, mas ainda assim era mais fácil do que prever as ações futuras do Congresso
  • Uma boa abordagem é mapear o ZIP code para um fuso horário nomeado, como US/Eastern. Depois, se você precisar do offset UTC, aplica esse fuso à data correspondente com pytz e obtém o offset
    Fusos horários nomeados são especiais porque são estáveis. Fusos de offset UTC como -05:00, ou abreviações como EST, não são estáveis ao longo do tempo em um local específico por causa do horário de verão
    Se você perguntar o fuso horário de alguém oferecendo offsets ou abreviações como opções, todo mundo fica confuso
  • Fiz algo parecido no começo deste ano: usei um serviço de geolocalização para converter o endereço em latitude/longitude e, em seguida, obtive o fuso horário a partir da latitude/longitude. Para estados com um único fuso, deixei um atalho
    Para a conversão latitude/longitude → fuso horário, usei esta biblioteca Python: https://github.com/jannikmi/timezonefinder
    A fonte dos dados também parecia ser de qualidade bem alta: https://github.com/evansiroky/timezone-boundary-builder/rele...
  • É preciso ter muito cuidado com identificadores Etc. Especialmente se você pretendia expor todos os identificadores diretamente ao usuário
    Esse arquivo tem um comentário dizendo: “POSIX considera positivo o que fica a oeste de Greenwich, mas muita gente espera que positivo seja a leste de Greenwich. Por exemplo, TZ='Etc/GMT+4' usa a abreviação -04 e significa 4 horas atrás de UT, ou seja, a oeste de Greenwich, mas muita gente espera que seja a leste, 4 horas à frente de UT”

• O fuso horário da Palestina também é bem estranho
  https://en.wikipedia.org/wiki/Time_in_the_State_of_Palestine
  Há horário de verão, mas as datas não são fixas; o governo anuncia todo ano quando começa e quando termina. Às vezes anunciam com menos de uma semana de antecedência, então todo tipo de problema interessante acaba surgindo

  • Acontece o fenômeno de duas pessoas que vivem no mesmo lugar físico seguirem horários atuais diferentes dependendo de sua identidade étnica e geopolítica
    As datas de início e término do horário de verão em Israel e na Palestina não são necessariamente as mesmas
  • Não sei se ainda é assim, mas o Brasil também era assim no passado. Por causa disso, uma vez quase perdi um voo
  • Isso aparece no texto original e está ligado ao Ramadã
  • Mesmo sem entrar a fundo em política, é difícil entender por que priorizam esforço no horário de verão. Parece haver preocupações muito maiores

• Acho que chamar um horário de verão com diferença de 30 minutos, e não de 1 hora, de “o fuso horário mais estranho” é estabelecer um critério baixo demais
  Quase todo o resto é mais estranho. Antarctica/Troll com certeza soa mais estranho, e os fusos horários de Marrocos e Gaza têm regras pelo menos de outro tipo, a ponto de não poderem ser expressos pelo sistema existente. Os fusos horários que entraram na lista de bloqueio da Apple, com transições na véspera de determinadas datas, também são estranhos o bastante para quebrar alguma coisa
  Concordo quanto aos segundos intercalares. São quase uma curiosidade, mais do que um conhecimento útil que um programador precise ter. Computadores aplicam smear aos segundos intercalares e nem sabem quando eles aconteceram. Dá para viver esquecendo completamente disso
  Dito isso, houve um momento em que países passaram de uma forma que ignorava segundos intercalares para uma forma que os considerava; portanto, a mudança na Austrália, décadas atrás, de GMT+x para UTC+x foi uma transição de ignorá-los para incluí-los. Talvez seja até melhor que esse fato seja ignorado quase universalmente

  • Em geral, concordo que segundos intercalares são uma curiosidade
    Mas sempre acho meio engraçado quando uma grande organização diz que “nossos servidores têm precisão de tempo abaixo de milissegundos graças à sincronização por GPS e a placas PCIe de relógio atômico de rubídio desenvolvidas internamente”, e ao mesmo tempo diz que “como fazemos smear do segundo intercalar ao longo de um dia, não tem problema se, na prática, o horário do servidor estiver errado em ±0,5 segundo”
    [1] https://engineering.fb.com/2021/08/11/open-source/time-appli...
    [2] https://engineering.fb.com/2020/03/18/production-engineering...
  • As datas do Ramadã não são valores bem conhecidos. Isso porque se baseiam em se a lua pode de fato ser vista em uma região específica da Terra
    Por exemplo, se o céu estiver muito nublado, não dá para ver a lua, não importa onde ela esteja. Isso causa problemas ao implementar calendários na administração de um país
    Muitos países que adotaram oficialmente o calendário islâmico usam datas aproximadas calculadas com antecedência com base na visibilidade prevista em um local específico. Portanto, o calendário islâmico na verdade não é um só; é mais como dois: o calendário islâmico observacional e um calendário preditivo, e ambos dependem do local onde a observação real ou prevista é feita
    Não sei como Marrocos ou Gaza fazem
  • Antarctica/Troll não é tão estranho assim. Na prática, usa o horário da Cidade do Cabo durante o curto verão e o horário da Noruega no restante do período
    Só que o horário da Noruega, por acaso, usa horário de verão
  • Segundos intercalares são, em geral, uma curiosidade, mas se tornam decisivos em aplicações nas quais várias partes precisam concordar exatamente sobre a ordem temporal. O exemplo clássico são transações financeiras
    Muitos mercados fecharam durante segundos intercalares, e muitos bancos ainda suspendem todas as transações durante mudanças de horário local para reduzir o risco de erros
    Mesmo em aplicações que não ligam muito para isso, houve uma quantidade surpreendente de bugs relacionados a segundos intercalares, e há bons motivos para a CGPM ter decidido abolir os segundos intercalares
    https://en.wikipedia.org/wiki/Leap_second#Other_reported_sof...
  • Vim procurar Troll. Até onde sei, é o único lugar com horário de verão de inverno, e ganha pontos extras pelo nome

• Um excelente texto sobre as acrobacias dos softwares de fuso horário. Eles são mesmo bastante flexíveis
  Se tudo for um conjunto finito de offsets automatizados, não há motivo para a política de horário de verão precisar se ajustar a mudanças de 60 minutos
  Será que algum país poderia decidir usar um offset que varia continuamente ao longo do ano inteiro? A tabela de consulta de offsets ficaria muito mais longa, mas isso poderia “resolver” o horário de verão. Como o ajuste seria contínuo e em pequenos incrementos, ninguém perceberia, como acontece com segundos intercalares
  Pessoas que dependem de relógios analógicos talvez nem precisassem mais ajustá-los sempre na mesma direção

  • Desde que a sincronização de relógios em dispositivos eletrônicos se tornou comum, venho sugerindo a qualquer um que me escute que adiantemos 10 minutos no primeiro domingo de cada mês durante 6 meses, e atrasemos 10 minutos no primeiro domingo de cada mês durante os outros 6 meses
    Uma mudança de 10 minutos uma vez por mês é muito mais fácil de se adaptar, quase imperceptível, e, se você perder, não é tão grave quanto ficar 1 hora errado
  • Se você seguir por esse caminho, a conclusão lógica é eliminar o próprio conceito de fuso horário e voltar ao horário solar local
  • Você está ignorando a maneira mais fácil de “resolver” o horário de verão
    Basta acabar com o horário de verão. Pessoalmente, prefiro horário padrão permanente a horário de verão permanente, mas aceitaria qualquer coisa desde que parássemos de mudar os relógios duas vezes por ano
  • A Índia usa UTC+5:30 e não adota horário de verão, o que torna interessante sua interação com o mundo
    Claro, a China é famosa por ter apenas um fuso horário apesar de ser tão extensa, o que cria situações interessantes tanto internamente quanto externamente
  • Em teoria, isso pode ser representado pela tzdb. Claro que causaria problemas
    Uma suposição realmente importante que não aparece de forma explícita no formato de dados TZif é que, ao converter horário local para horário UTC, há no máximo duas possibilidades
    Muito software se apoia nessa suposição e, por exemplo, java.time.LocalDateTime tem withLaterOffsetAtOverlap(): https://docs.oracle.com/javase/8/docs/api/?java/time/LocalDa...
    Isso presume implicitamente que, quando há ambiguidade sobre o que significa 2:30 da manhã, as únicas soluções possíveis são as duas, antes e depois do horário de verão. Se algum fuso horário atrasar uma vez às 2:00 da manhã e de novo às 2:15, criando três ou mais soluções, muita coisa não conseguirá representar isso

• O que gosto no banco de dados tz é que, tecnicamente, ele é um diff de um diff
  Como ele armazena como a diferença entre cada fuso horário e o UTC mudou historicamente, pode ser visto como diff^2. Mas o banco de dados tz também recebe atualizações, então esses commits são um diff do diff do diff, ou seja, diff^3
  Dá para ir mais longe. Há um changelog, e esse changelog é armazenado no git, então um commit no changelog da tz é uma alteração na lista de alterações da lista de alterações da lista de alterações em relação ao UTC: diff^4

  • Você deixou de fora que o UTC, e de forma mais ampla a própria medição do tempo, também é um diff
  • Um diff de um diff é apenas dois diffs. Não é uma multiplicação de diffs

• Acho que o enquadramento essencial é que quase toda data/hora é, na verdade, um conjunto de regras de correspondência sob observação
  Você pode estimar quantos segundos faltam até que uma correspondência seja acionada, mas não pode ter certeza absoluta até que ela aconteça de fato, e, em alguns casos, ela pode nem acontecer exatamente
  A outra metade é transformar a estimativa de delta “provavelmente vai acontecer em X segundos a partir de agora” de volta em “nesse momento, o relógio do seu fuso horário provavelmente vai mostrar Y”
  É preciso lembrar de acompanhar qual fuso horário controla o evento e em qual fuso horário ele é exibido
  [1] A estimativa em UTC pode errar para mais ou para menos pelo tamanho de um segundo intercalar. TAI é mais seguro, mas isso pode mudar se alguém descobrir algo novo e interessante que altere o comportamento dos átomos de césio
  [0] Por exemplo, um país pode deixar de existir e o fuso horário desaparecer. Ou o relógio pode pular de 1:00 para 2:00, fazendo com que o intervalo de 1:30 a 2:00 nunca aconteça exatamente por causa da hora omitida