Mostrar código-fonte de Era Unix

{{mais notas|data=dezembro de 2013}}
<div style="text-align:center;border:1px solid #dbdbdb;border-radius:4px;padding:5px;width:220px;margin-left:4em;float:right;">'''Hora atual Unix'''{{Efn|O horário Unix time quando esta página foi gerada pela última vez}}<br>{{#time:U}} {{purge|(atualizar)}}<br>([[ISO 8601|{{#time:Y-m-d H:i:s}}Z]])</div>[[Imagem:1000000000seconds.jpg|right|thumb|220px|Horário Unix chegando em 1.000.000.000 segundos em  2001-09-09T01:46:40Z. Celebrado em Copenhagen, Dinamarca em uma festa promovida pela [[Danish UNIX User Group|DKUUG]] (às 03:46:40 no horário local).]]

A '''Era UNIX''' ou ''Posix Time'' ou ''Unix epoch'' ou ''Unix Timestamp'' teve início no dia a [[1 de janeiro]] de [[1970]]<ref name=ec>{{Citar web | titulo= Conversor Epoch | url=https://dateconvertor.com/en/ | publicado= dateconvertor.com | autor=Misja Op de Coul | acessodata= 28/7/2012}}</ref>. 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 [[segundo]]s passados desde o ''epoch'', não considerando [[segundo bissexto|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álculo]]s com datas em [[computador]]es, 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 [[registro]]s 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<ref name=ec/>, 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):

<math>1095379198+12\cdot 86400+10\cdot 3600+40\cdot 60=1096454398</math>

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 do ano 2038|problema para o ano de 2038]] desta vez associado à data no formato marca temporal UNIX.<ref name=ntp>{{Citar web | titulo= Ntp era and era numbering | url=http://www.eecis.udel.edu/~mills/y2k.html |publicado= [[Universidade de Delaware]] | autor=L. Frank Baum | acessodata= 28/7/2012}}</ref>

[[Imagem:Year 2038 problem.gif|thumb|400px|Exemplo mostrando o que irá acontecer em 2038.]]

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.

== Ver também ==
* [[Problema do ano 2038]]
* [[Network Time Protocol]]
* [[Tempo Atômico Internacional]]
* [[Tempo Universal Coordenado]]
==Notas==
{{listanota}}

==Referências==
{{Referências}}

== Ligações externas ==
* [https://web.archive.org/web/20080518013206/http://cm.bell-labs.com/cm/cs/who/dmr/1stEdman.html Primeira edição do manual de programação Unix]
*[https://www.unixtimeconverter.net/pt/ Conversor de Unix Timestamp para Data e vice-versa]
* [http://unixepoch.com O apocalipse do UNIX timestamp]
* [http://unixtimestamp.50x.eu/ Conversor UNIX timestamp]
* [http://esqsoft.com/javascript_examples/date-to-epoch.htm Ferramenta on-line para converter datas para e do formato UNIX]
* [https://web.archive.org/web/20070617034624/http://soft.zoneo.net/Unixtime/index.php Unixtime online: Converte data UNIX para texto (inglês)]

[[Categoria:Unix]]
[[Categoria:Escalas de tempo]]