Estou curioso porque um valor inteiro assinado foi usado para manter o tempo do Unix. É claro que seria mais sensato usar um inteiro sem sinal, já que o tempo não pode retroceder, então ter um valor negativo para o tempo é, bem, impossível. No entanto, em 19 de janeiro de 2038 o tempo do Unix transbordará e será o fim do tempo como muitos de nós sabemos. Nós iremos de 2.147.483.647 para -2.147.483.648 ... Não é bom.
Então, por que um inteiro assinado foi usado e quão difícil seria implementar uma correção para isso quando o fim do tempo se aproxima?
O OpenBSD, há algum tempo, mudou de um valor de tempo de 32 para 64 bits, o que dá espaço para respirar até o final do tempo. Quão difícil será essa correção dependerá do unix e de quão bem ele é suportado (e de quão próximo do tempo de 2038 se move).
% date -r $((2**31))
Tue Jan 19 03:14:08 GMT 2038
% date -r $((2**51))
Mon Jun 19 13:54:08 GMT 71358665
Tags time