Espere um segundo mais…

O leap second traz algum impacto para a Internet ou para a área de TI?

Praticamente todo profissional de TI ao menos as vezes reclama do tempo. Pra ser mais preciso, da falta de tempo. Pois bem, 2015 será um ano longo… Todos teremos tempo de sobra. Ao menos um segundo a mais, de sobra. Mas será que realmente devemos comemorar isso?

O que é esse tal de leap second? É justamente o que o título desse artigo sugere: um segundo a mais, acrescentado na virada do dia 30 de Junho de 2015, para o dia 01 de Julho [1]. Ou seja, os relógios devem contar:

23h59m59s 30/06/2015
23h59m60s 30/06/2015 <—– leap second = segundo extra
00h00m00s 01/07/2015

Na verdade, na maior parte do Brasil estamos no fuso horário UTC-3, então, para nós isso não acontecerá a meia noite, mas sim as 20h59:

20h59m59s 30/06/2015
20h59m60s 30/06/2015 <—— leap second = segundo extra
21h00m00s 30/06/2015

Os profissionais de TI devem se preocupar com isso? Infelizmente sim. Em junho de 2012, na última vez em que houve um leap second, vários sites importantes na Internet (como exemplo o próprio Linkedin [2]) tiveram problemas sérios. Praticamente todos que usavam aplicações Java, e alguns dos que usavam o sistema operacional Linux sofreram problemas, como travamentos ou lentidão. Em dezembro de 2008, na penúltima ocorrência do leap second, muitos sistemas Linux apresentaram também travamentos, embora com impactos menores do que em 2012.

Não há razão para alarme, mas pode haver alguns problemas. Embora os bugs específicos que causaram dificuldades em 2008 e 2012 tenham sido corrigidos, acredito que no mínimo é prudente:

1. Estudar a situação, procurando entender se e como seus sistemas podem ser afetados.
2. Zelar para os seus sistemas estejam corretamente configurados, usando NTP.
3. Realizar testes em ambiente apropriado, com antecedência, simulando o leap second que acontecerá em 30 de Junho.
4. Programar um plantão para o dia e horário do evento, executando testes apropriados em seus sistemas logo após o leap second.

O que é o leap second? Por que ele é necessário?

Por que existem os leap seconds? É simples. Historicamente medimos o tempo olhando o céu. Acho que todos já viram por aí o termo GMT (Greenwich Mean Time). A posição do Sol medida pelo Observatório Real, em Greenwich, Londres, foi referência por muito tempo para a medida do tempo. Contudo, nem a rotação da Terra, nem sua translação em torno do Sol são tão precisas.

Desde 1967 o tempo é medido por relógios atômicos. Atualmente, a definição do segundo se baseia nas variações no estado dos átomos do Césio. Isso garante precisão e acurácia muito superiores as das medições baseadas em observações astronômicas. Relógios Atômicos, com Césio, estão em laboratórios metrológicos por todo o mundo. Cada país mantem suas próprias referências de tempo. Todos esses laboratórios, contudo, estão integrados, comparando constantemente seus relógios e definindo a escala de tempo que é usada como padrão em todo o mundo. No Brasil, o Observatório Nacional é o responsável pela medição oficial de tempo.

Na verdade existem algumas escalas de tempo diferentes [1]. A escala que é definida diretamente com base nos relógios de Césio chama-se TAI (Tempo Atômico Internacional). Você pode imaginar, contudo, que já que a rotação da Terra não é tão precisa assim, com o tempo, haveria diferenças entre o tempo medido pelo Sol (equivalente ao antigo GMT) e essa nova escala. Ou seja, ao meio dia, depois de alguns anos, o Sol já não estaria mais a pino. Na verdade, sabe-se que a Terra está desacelerando sua rotação lentamente, por causa principalmente do “atrito” causado por nosso satélite natural, a Lua: os dias estão ficando ligeiramente mais longos.

Para uso civil, no dia a dia, é muito mais cômodo continuarmos nos baseando no Sol. Foi criada então uma escala de tempo apropriada, o UTC (Tempo Universal Coordenado). UTC é basicamente equivalente a TAI (no sentido de que o segundo é medido da mesma forma), mas acrescentamos ou ‘pulamos’ um segundo sempre que for necessário, para manter a sincronia com o Sol. Esse segundo a mais, ou a menos, é o leap second. Não há uma periodicidade definida pra isso acontecer. Apesar de na média, lentamente, a rotação da Terra estar desacelerando, ela não é regular. Para o uso no dia a dia, então, o UTC é basicamente equivalente ao antigo GMT.

OK. Já sei o que são leap seconds. Mas por que eles podem travar meu computador?

Os computadores são muito sensíveis ao tempo. O pessoal que escreve softwares, os programadores, sempre consideram duas coisas como verdade, talvez sem parar muito pra pensar no assunto:

• O tempo sempre avança: ou seja, sempre anda pra frente. Não dá pra voltar no tempo, isso é óbvio, não é? Mas o que impede que alguém acerte o relógio do computador para uma data no passado? Nada. Isso pode levar a medições nulas ou negativas de tempo pelos programas, uma situação que talvez não esteja devidamente tratada, por ser inesperada, o que pode levar aos resultados mais diversos e imprevistos.
• Os computadores estão sincronizados entre si: o usuário fez uma transação financeira importante via Internet as 14h35m16s. OK. Mas em que relógio? E se o relógio do computador do usuário não estiver em sincronia com o da loja ou banco? E se os computadores dentro desse banco, loja, ou qualquer outra empresa não estiverem em sincronia? Os softwares normalmente consideram que eles estão. Guardam registros baseados nesses horários. Fazem cálculos baseados nesses horários. Por exemplo, alguns algoritmos de criptografia simplesmente deixam de funcionar se os relógios dos computadores que participam da comunicação não estiverem sincronizados entre si.

Normalmente o NTP, uma tecnologia que permite aos computadores manterem os relógios sincronizados entre si, e com o padrão de tempo mundial, é parte da solução para esse ‘problema’. Se quiser saber mais sobre o NTP em si, veja o vídeo a seguir:

O leap second também é tratado pelo NTP e pelos sistemas operacionais dos computadores, contudo, 2008 e 2012 nos provaram que talvez não tão bem assim.

Os problemas relacionados ao leap second podem acontecer basicamente por duas razões:

• Problemas (bugs) na forma que os leap seconds em si são tratados pelo NTP ou pelos sistemas operacionais. Essa é uma parte do código que só é executada uma vez a cada alguns anos e, se testes adequados de regressão não tiverem sido incluídos no ciclo de desenvolvimento, pode haver problemas.
• Problemas (bugs) pela forma que o segundo extra é tratado pelos demais softwares. Pode ser que o sistema operacional apresente o segundo extra, por exemplo, como uma repetição do último segundo do ano: 23h59m59s duas vezes… Isso poderia levar a medições de tempo nulas ou negativas, gerando erros talvez não previstos e tratados adequadamente.

Devo então parar de usar o NTP ou desligá-lo no dia? Ouvi dizer que o Google faz algo parecido.

Não! Eu penso no NTP como parte da solução (para a necessidade dos computadores trabalharem sincronizados entre si, com o tempo sempre avançando, e sincronizados com um padrão mundial de tempo). E não como parte do problema. Recomendo o uso do NTP (e do www.ntp.br). Dito isso…

O Google adotou uma solução curiosa já há algum tempo [4]. Eles modificaram o tratamento do tempo em seus sistemas, de forma que o leap second é ‘inserido’ com um ligeiro aumento (ou diminuição, se for o caso) da frequência dos relógios no dia previsto, de forma que o tempo vai variando lentamente até que à meia noite, os relógios já estão ‘adiantados’ 1s. Isso garante que o tempo vai sempre avançar para todos os softwares e, dentro do ambiente do Google pode garantir que os computadores continuam sincronizados entre si.

Mas eles perdem ao menos por um dia o sincronismo com o resto do mundo. Isso aparentemente não é um problema para o Google, dada a natureza dos sistemas que operam. Esses sistemas aparentemente toleram a eventual diferença de até 1s entre eles e o resto do mundo. Talvez para outro tipo de empresa contudo, isso seja completamente inviável. Não vejo, por exemplo, a solução do Google sendo adotada pelo mercado financeiro, a menos que fosse algo padronizado e adotado globalmente.

O que aconteceu em 2008 e 2012 deixou claro que a solução atual tem problemas. Talvez a solução do Google deva ser estudada com mais seriedade, mas não para ser aplicada de forma isolada, na sua ou na minha empresa. Só faria realmente sentido, se fosse padronizada.

Aviões vão colidir? Navios vão se perder? Drones atingirão alvos errados? A Internet irá parar? Não teremos energia elétrica? Será o caos e o fim da civilização conhecida?

Não. Não se espera nenhum desastre nem consequências tão drásticas. Se em 2008 e 2012, quando havia menos consciência do problema, não ocorreu nada assim… Se aprendemos já com os bugs e erros de 2008 e 2012 e os softwares estão mais maduros… Então não será agora que teremos caos…

O sistema GPS, que poderia ser motivo de preocupação, não usa UTC. Não considera leap seconds. Obviamente os receptores GPS domésticos que usamos nos smartphones ou carros fazem a devida correção antes de nos mostrar o horário, e até podem eventualmente falhar (isso aconteceu em 2003 com alguns modelos). Mas o sistema GPS em si está a salvo desse tipo de problema.

Por que não acabamos simplesmente com essa história de leap seconds? Não seria melhor?

Alguns acreditam que sim. O assunto, contudo, é controverso e está em discussão na ITU: https://itu4u.wordpress.com/2013/10/11/time-to-leave-leap-seconds-behind/. Aparentemente haverá uma decisão neste ano.

E se nós acelerássemos a rotação da Terra para manter a sincronia naturalmente com os relógios de Césio?

O assunto foi discutido divertidamente nessa edição de what if do xkcd: https://what-if.xkcd.com/26/.

Aparentemente não é viável, ao menos não sem matar praticamente toda a população do planeta. Daí de qualquer forma não precisaríamos nos preocupar com os leap seconds.

Apesar de ser humorístico, vale ler o artigo (em inglês), ao menos pela forma didática com que explicam a desaceleração.

O que fazer, então?

Repito as sugestões do início deste (longo) artigo, para o caso de ter se esquecido delas depois de chegar tão longe…

Acredito que no mínimo é prudente:

1. Estudar a situação, procurando entender se e como seus sistemas podem ser afetados.
2. Zelar para os seus sistemas estejam corretamente configurados, usando NTP.
3. Realizar testes em ambiente apropriado, com antecedência, simulando o leap second que acontecerá em 30 de Junho.
4. Programar um plantão para o dia e horário do evento, executando testes apropriados em seus sistemas logo após o leap second.

Referências

[1] http://en.wikipedia.org/wiki/Leap_second
[2] http://www.wired.com/2012/07/leap-second-bug-wreaks-havoc-with-java-linux/
[3] http://stjarnhimlen.se/comp/time.html
[4] http://googleblog.blogspot.com.br/2011/09/time-technology-and-leaping-seconds.html