quinta-feira, 12 de fevereiro de 2009

Sexta-feira 13, às 23:31:30 GMT: UNIX time_t 1234567890

Essa é para os mais nerds e programadores: dia 13 de fevereiro de 2009 aos 30 segundos das 20h31min (ou 20:31:30 para os viciados em 24 horas), horário de Brasilia, já contando o fuso horário, horário de verão) terão se passado 1234567890 segundos desde a criação do Unix Time.

Mas… O que é mesmo esse tal de Unix Time? Resumindo de forma muito tosca: é uma forma de contagem de tempo usada em muitos sistemas operacionais (e outros sistemas) para descrever o tempo de uma forma padronizada, e facilitar operações de soma ou subtração entre datas. Assim, para saber quanto tempo se passou entre 18/09/1982 e 12/02/2009 (a data desse post) eu só preciso:

a) Converter a primeira data para Unix Time (usando time.mktime do Python, por exemplo), obtendo o valor em segundos entre 00:00:00 01/01/1970 e 00:00:00 18/09/1982

b) Converter a segunda data para Unix Time (com o mesmo processo, e obtendo um novo valor em segundos)

c) Subtrair o valor menor maior do valor maior

d) Você terá a diferença em segundos das duas datas. Seguindo aquela ordem matemática simples, divida por 60 para saber os minutos, divida por 60 para as horas, e por 24 para os dias.

Dá pra fazer muito mais com o Unix time, mas isso não importa. O que importa é que em 20:31:30 13/02/2009 será um dos momentos mais nerds da história: 1234567890 segundos desde o Unix Time!

Pra quem é como eu e gosta de verificar as coisas, lá vai minha verificação, em Python:

Errar é humano... Colocar a culpa no computador é mais ainda.
vindemiatrix@sorvete:~$ python
Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> x = time.strptime("13 02 2009 20 31 30 GMT", "%d %m %Y %H %M %S %Z")
>>> y = time.mktime(x)
>>> x
(2009, 2, 13, 20, 31, 30, 4, 44, 0)
>>> y
1234567890.0

Fonte: http://www.guravehaato.info/geek-life/quase-1234567890-segundos-desde-1970/

Ainda falando em UnixTime, teremos outro problema como o da virada no ano 2000, mas no ano de 2038.

O problema afeta os programas que utilizam a representação de tempo POSIX, em que a data é calculada através do número de segundos (ignorando os segundos bissextos) desde 1 de janeiro de 1970. Esta representação é padrão nos sistemas operacionais do tipo Unix e afeta a maioria dos sistemas, pois grande parte deste software foi desenvolvido na linguagem C. Na maioria dos sistemas de 32 bits, o tipo de dados time_t, utilizado para armazenar esta contagem de segundos, é um inteiro de 32 bits do tipo signed (considera o sinal). O último registro de tempo que pode ser representado por este formato, seguindo o padrão POSIX, é 03:14:07 na terça-feira 19 de janeiro de 2038 (UTC). Após este momento a data será representada por um número decimal negativo que, dependendo da implementação, corresponderá ao ano 1970 ou 1901. Este valor para a data corrente certamente resultará em erros de cálculo e de funcionamento na maior parte dos programas em execução pelo sistema.

Solução

Não há maneira simples de resolver este problema para os sistemas existentes. Alterar a definição do time_t para 64 bits pode quebrar a compatibilidade binária de softwares, dados persistidos e de qualquer sistema que manipule datas representadas no formato binário. Alterar o time_t para um inteiro de 32 bits unsigned (não considera o sinal) pode alterar vários programas que trabalham com diferenças de tempo.

A maioria dos sistemas que suportam a arquitetura de 64 bits já suportam o time_t de 64 bits. A migração para esta arquitetura já está em andamento e muitos esperam que ela esteja completa até 2038. Porém, milhões de sistemas de 32 bits foram instalados até o ano de 2006, muitos em sistemas embarcados, e é muito incerto se eles serão totalmente substituídos até 2038. Apesar de, normalmente, os sistemas serem atualizados num prazo de 18-24 meses, os sistemas embarcados podem operar sem alterações por toda a vida do sistema que controlam. A utilização do time_t de 32 bits foi codificada em alguns formatos de arquivo, como o ZIP, o que significa que o problema pode permanecer por um longo período após a expiração da vida útil das máquinas envolvidas.

A utilização de valores de 64 bits introduz um novo “corte” na data em aproximadamente 290 bilhões de anos, num domingo em 4 de dezembro de 292.277.026.596 as 15:30:08 (UTC). Claramente este problema não é uma questão imediata.

Fonte: http://pt.wikipedia.org/wiki/Problema_do_ano_2038.

Se quizer saber mais sobre as várias datas que influem em sistemas computacionais de alguma forma, dê uma olhada no site Critical and Significant Dates. Vc vai ver muita coisa interessante e muita coisa tb inútil. Mas vale a pena gastar alguns segundos nele. Vc já perdeu vários aqui hehehe!