Como eu configuro um sistema Unix para rodar no tempo do TAI?

4

Eu quero configurar um sistema Unix para ser executado no Tempo Atômico Internacional (TAI) para poder ver o segundo bissexto final do ano foi reportado corretamente em 2016-12-31 23:59:60. Eu sei que isso fará com que os timestamps do sistema sejam incompatíveis com os POSIX, mas estou fazendo isso como um experimento. Já copiei o arquivo de fuso horário de /usr/share/zoneinfo/right/ para /etc/localtime . Estas são minhas perguntas.

  • Como posso definir com precisão a hora do sistema? Eu entendo que deve ser definido para segundos TAI, em vez de segundos UTC. É possível fazer isso via NTP? Atualmente, o sistema exibe o tempo 36 segundos fora do correto.
  • A hora exibida continuará correta após 2017-02-01? Os arquivos zoneinfo/right timezone precisam ser atualizados?
por Diomidis Spinellis 25.12.2016 / 21:44

2 respostas

0

Arquivos de fuso horário podem precisar ser atualizados. Você pode testá-lo executando um comando para ver as transições no arquivo de fuso horário instalado. O exemplo a seguir contém uma transição bissexto.

$ zdump -c 2017,2018 -v /etc/localtime /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL /etc/localtime Sat Dec 31 23:59:60 2016 UT = Sun Jan 1 01:59:60 2017 EET isdst=0 gmtoff=7200 /etc/localtime Sun Jan 1 00:00:00 2017 UT = Sun Jan 1 02:00:00 2017 EET isdst=0 gmtoff=7200 /etc/localtime Sun Mar 26 00:59:59 2017 UT = Sun Mar 26 02:59:59 2017 EET isdst=0 gmtoff=7200 /etc/localtime Sun Mar 26 01:00:00 2017 UT = Sun Mar 26 04:00:00 2017 EEST isdst=1 gmtoff=10800 /etc/localtime Sun Oct 29 00:59:59 2017 UT = Sun Oct 29 03:59:59 2017 EEST isdst=1 gmtoff=10800 /etc/localtime Sun Oct 29 01:00:00 2017 UT = Sun Oct 29 03:00:00 2017 EET isdst=0 gmtoff=7200 /etc/localtime 9223372036854689407 = NULL /etc/localtime 9223372036854775807 = NULL

Se o arquivo de fuso horário precisar ser atualizado e se nenhum arquivo de fuso horário de segundo (/ direito) for fornecido pela distribuição do sistema operacional, você poderá configurar o arquivo de fuso horário da seguinte forma.

  • busque a distribuição de fuso horário de link
  • configurar e instalar e
  • configure o arquivo de zona correto (que também inclui informações de segundo intercalado) com um comando como o seguinte

sudo cp tzdir /etc/zoneinfo-leaps/ seu fuso horário /etc/localtime

Para definir a hora de um servidor NTP, você pode configurar e instalar o rdate (openrdate) e, em seguida, executar um comando como sudo rdate -s -c -n 0.gentoo.pool.ntp.org .

    
por 01.01.2017 / 22:42
2

Primeiro, a noção de que o relógio em um sistema de computador deve ser fornecido como TAI ou UTC não é estritamente preciso. Eu posso obter e definir a hora com fusos horários, por exemplo, o comando GNU coreutils date é muito flexível. Em um sistema definido para a direita / UTC (mais sobre isso mais tarde):

# date -s "Tue Dec 27 08:16:53 CST 2016"
Tue Dec 27 14:16:53 UTC 2016

Veja a programação de tempo, relógio e calendário da ESR em C para as estruturas de dados reais envolvidas, e algumas boas referências.

Você ainda pode configurar o comando ntp, ptp ou emitir o comando date ou chronyc settime no tempo certo, como de costume.

No entanto, você precisa entender o deslocamento do TAI - UTC e qual é o seu tempo de origem. A hora do NTP é padrão UTC, portanto, basta definir uma zona "certa" em um sistema sincronizado UTC com o TAI - 10 - UTC, que atualmente é 26.

Em vez disso, alguns servidores NTP podem fornecer GPS ou TAI. Isso mais alguns hacks leap segundos vão se livrar do segundo erro corrigido pelo kernel ou sincronização de tempo de usuário. Veja: arquivos de banco de dados "right" tz (zoneinfo) e NTP baseado em GPS

Cuidado com o fato de 86401 segundos dias serem fora do padrão e contra o que o POSIX supostamente requer. Se configurar servidores NTP que fazem isso, eles não podem fornecer tempo para outros sistemas. Também pode resultar em comportamentos estranhos de aplicativos que dependiam de um tempo particularmente formatado.

Os dados do TZ precisarão ser atualizados duas vezes por ano para capturar os segundos bissextos. Se você consertar segundos pulados por esse motivo, precisará fazer isso novamente. (É muito provável que você já precise atualizar outro software com mais frequência do que isso por vários motivos.) Haverá segundos bissextos adicionais, a mudança de rotação da Terra é uma necessidade física. Há também uma necessidade política do provável fuso horário e alterações do horário de verão por ... menos razões técnicas.

Bom momento, já que o segundo bissexto seguinte é 31 de dezembro às 23h 59m 60s
. A Red Hat publicou um bom resumo das maneiras de lidar com isso no Linux se alguém estiver usando o UTC. Observe que muitos sites repetem, mancham ou deixam o NTP corrigir o segundo erro sem precisar mostrar o 61º segundo. Resolva os problemas do Segundo Salto no Red Hat Enterprise Linux

Tudo isso parece ser muito trabalhoso para mim. Eu prefiro não ver o 61º segundo, se eu pudesse deixar o NTP ou o kernel lidar com isso, através dos métodos descritos pela Red Hat.

    
por 27.12.2016 / 15:26