Era Unix
Origem: Wikipédia, a enciclopédia livre.
A Era UNIX teve início no dia 1 de janeiro de 1970. O nome se deve ao fato de esta data, 01/01/1970 00:00:00 UTC, ser o marco zero do sistema de calendário usado pelo sistema operacional UNIX. Também pode ser chamada de era POSIX.
Índice |
[editar] 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 analizados 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 95 minutos, antes de somar as 10 horas precisaríamos corrigir este valor, portanto o minuto seria 35 e a hora somaria 1, porem 24 horas também precisa ser corrigido para 0 o que somaria 1 no dia, resultando em 23/08/1980 0:35:12, 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.
[editar] UNIX timestamp
Para resolver problemas do tipo dos citados acima e para unificar um formato de data foi criado o UNIX timestamp que é uma forma de calendário amplamente utilizada em sistemas computacionais principalmente os baseados no sistema operacional UNIX.
O UNIX timestamp é simplesmente um contador que teve seu valor zero associado com a data 01/01/1970 00:00:00UTC, 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 UNIX timestamp 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.
[editar] 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 às data no formato UNIX timestamp.
O problema está no fato de que os computadores normalmente armazenam o timestamp em uma variável do tipo time_t que é declarada como uma signed int32 este tipo de variável pode armazenar números positivos de 0 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 passara 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 (mais de 68 para trás).
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 calculos e comparações com as datas, e de criar um novo problema semelhante no anos de 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_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.
