Era Unix
A Era UNIX ou Posix Time ou Unix epoch ou Unix Timestamp teve início no dia a 1 de janeiro de 1970[1]. O nome se deve ao fato de esta data, dia 1 de janeiro de 1970 às 00:00:00 do Tempo Universal Coordenado (UTC) no calendário gregoriano proléptico, ser o marco zero do sistema de calendário usado pelo sistema operacional UNIX. Também pode ser chamada de era POSIX.
O horário Unix, definido como o número de segundos passados desde o epoch, não considerando segundos bissextos, é largamente utilizado em sistema operacionais do tipo Unix bem como em outros sistemas. Ele não é uma representação linear nem uma representação verdadeira do tempo UTC, por não considerar os segundos bissextos (e.g. 31-12-1998-12 23:59:60).
Motivação
Apesar do calendário gregoriano facilitar o raciocínio cronológico para os humanos, quando se deseja realizar comparações lógicas ou cálculos com datas em computadores, este tipo de calendário acaba dificultando o trabalho.
Por exemplo, para nós, saber o que aconteceu primeiro, se foi algo em 10/04/1977 12:45:15 ou algo em 10/03/1976 13:09:12 é algo quase automático mas para resolver isso em um computador todos os 6 campos teriam que ser analisados independentemente, apesar disso ser realizado quase que instantâneamente não deixa de ser um trabalho extra que o processador poderia evitar se fizesse uso de outro formato de data. Imaginemos um banco de dados com milhares de registros e o processador recebendo um comando para colocar tudo em ordem cronológica, se pudermos fazer as comparações com uma única operação por registro ao invés de 6 operações/registro o tempo final também tenderá a ser 6 vezes menor.
Outra situação seria: quanto dá a data 16/09/2004 23:59:58 UTC mais 12 dias, 10 horas e 40 minutos? A complicação neste tipo de cálculo está em corrigir o overflow conforme o processamento em etapas vai sendo feito. Ou seja, ao somar os 40 minutos na data teríamos 99 minutos, antes de somar as 10 horas precisaríamos corrigir este valor, portanto o minuto seria 39 e a hora somaria 1, porem 24 horas também precisa ser corrigido para 0 o que somaria 1 no dia, resultando em 17/09/2004 0:39:58, somente então somaríamos as 10 horas, faríamos as correções, somaríamos os dias e novamente faríamos correções. Vê-se facilmente que é um trabalho repetitivo que deveria ser evitado.
Marca temporal UNIX
Para resolver problemas do tipo dos citados acima e para unificar um formato de data foi criada a marca temporal UNIX, que é uma forma de calendário amplamente utilizada em sistemas computacionais principalmente os baseados no sistema operacional UNIX.
Ela é simplesmente um contador que teve seu valor zero associado com a data 01/01/1970 00:00:00UTC[1], e que é incrementado a cada segundo, assim:
- 01/01/1970 00:00:00 UTC → 0
- 01/01/1970 00:00:25 UTC → 25
- 01/01/1970 00:01:00 UTC → 60
- 01/01/1970 01:00:00 UTC → 3 600
- 02/01/1970 00:00:00 UTC → 86 400
- 31/12/1998 23:59:58 UTC → 915 148 798
- 01/01/1999 00:00:01 UTC → 915 148 801
- 16/09/2004 23:59:58 UTC → 1 095 379 198
Uma vez representadas no formato acima, as datas se tornam um pouco complicadas para o raciocínio humano mas são manipuladas muito facilmente pelos computadores, por exemplo, no caso da comparação entre datas com uma única operação o processador sabe se a data 17658546778 é maior ou não que a data 1765223546, e no caso dos cálculo seria algo como (usando o mesmo exemplo: 16/09/2004 23:59:58 UTC mais 12 dias, 10 horas e 40 minutos):
que é uma operação facilmente realizada pelos processadores, também em etapas, mas em menor quantidade que no caso do calendário gregoriano.
Problemas
Assim como houve a previsão de problemas na passagem do milénio (o bug do milénio), já se espera um problema para o ano de 2038 desta vez associado à data no formato marca temporal UNIX.[2]
O problema está no fato de que os computadores normalmente armazenam a marca temporal numa variável do tipo time t que é declarada como uma signed int32 este tipo de variável pode armazenar números de -2147483648 até 2147483647, sendo este último o valor do contador para a data de 19/02/2038 03:14:07 UTC.O que irá acontecer é que no próximo segundo o contador deveria avançar para 2147483648 mas como este número não cabe numa variável do tipo signed int32, o contador passará então a ser interpretado como sendo -2147483648 (negativo), o que fará com que o calendário dê um salto para a data de 13/12/1901 20:45:52 UTC.
A solução mais simples seria redefinir o tipo time_t para ser uma unsigned int32, mas isso tem o efeito colateral de complicar os cálculos e comparações com as datas, e de criar um novo problema semelhante no ano 2106, quando então o contador atingiria o valor máximo de 4294967296 passando em seguida para 0 o que retornaria para o ano de 1970 (um regresso de 136 anos).
A outra solução é redefinir o tipo time_t para signed int64 mas isso causa incompatibilidade com as datas já armazenadas no formato signed int32, porem se mostra a melhor opção por não ter mais problemas por cerca de 290 bilhões de anos.
