Isso está relacionado, mas acredito que não seja uma duplicata, de " Por que não consigo definir a data das minhas máquinas GNU/Linux para a Época? ".
Descobri que um dos meus kernels Linux rejeita tentativas de acertar o relógio para um horário durante os primeiros seis minutos após a época:
root@beaglebone:/# date 010100061970
date: cannot set date: Invalid argument
Thu 01 Jan 1970 12:06:00 AM UTC
root@beaglebone:/# date 010100071970
Thu 01 Jan 1970 12:07:00 AM UTC
Mas sete minutos depois da época funciona bem.
Alguém tem alguma ideia de por que isso pode acontecer? Quando tiver oportunidade, verificarei as fontes do kernel em busca de pistas.
(Não, não é uma questão prática, apenas curiosidade e, portanto, talvez mais adequada para retrocomputing.se ou algo assim. Minha tentativa de acertar o relógio dessa maneira foi um erro, e o kernel me fez um favor ao rejeitá-la. Mas, ainda assim, é estranho.)
Sei por outras evidências que a rejeição não está acontecendo no date
comando, mas no próprio kernel. O settimeofday
syscall está retornando -1, com errno definido como EINVAL.
Isso ocorreu em um sistema Debian 10 executando o kernel 4.19.94-ti-r42.
Eu também tentei em uma máquina Debian 11, kernel 5.10.179-1, e ele se comportou de forma semelhante, embora a "região proibida" fosse de dois meses inteiros no início de 1970 - não consegui definir uma data antes de março 1.
Atualização: Não apenas a pergunta foi respondida, mas o pequeno mistério estranho também foi resolvido, ou seja, por que diferentes máquinas nas quais testei tinham comportamentos diferentes. A primeira máquina em que testei havia sido reinicializada recentemente e não me permitia definir o tempo para um valor inferior a sete minutos após a época. Mas a segunda máquina estava em funcionamento há alguns meses e não me permitia definir a hora para uma data anterior a março - isto é, não dentro dos primeiros dois meses após a época. Mas isso faz sentido, porque uma maneira de declarar a restrição é que você não pode ter (tempo desde 1970) menor que (tempo desde a inicialização).
Isso é causado pelo commit e1d7ba873555 ("time: Always make sure wall_to_monotonic is't Positive") . Pela mensagem de commit: