A Era UNIX ou Posix Time ou Unix epoch ou Unix Timestamp teve início no dia a 1 de janeiro de 1970. 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).
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.
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, e que é incrementado a cada segundo, assim:
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):
{\displaystyle 1095379198+12\cdot 86400+10\cdot 3600+40\cdot 60=1096454398}
que é uma operação facilmente realizada pelos processadores, também em etapas, mas em menor quantidade que no caso do calendário gregoriano.
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.
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.