나는 Y2038 problem에서 읽었으며 부호 비트를 "증가"시키려고하기 때문에 time_t이 결국 가장 낮은 음수로 되돌아 간다는 것을 알고 있습니다.부호있는 정수로서의 시간
해당 위키 백과 페이지에 따르면 time_t을 부호없는 정수로 변경하면 초기 날짜를 처리하는 프로그램이 중단 될 수 있기 때문에 수행 할 수 없습니다. (어느 의미가 있습니다.)
그러나 처음에는 부호없는 정수가 아닌 이유를 알지 못합니다. 1970 년 1 월 1 일을 우스운 음수가 아닌 0으로 저장하는 것이 어떻습니까?
서명 된 -2,147,483,648에서 시작하는 것이 부호없는 0부터 시작하도록하는 것과 같습니다. 32 비트 정수가 보유 할 수있는 값의 범위는 변경되지 않습니다. 32 비트 정수는 4,294,967,296 개의 다른 상태를 유지할 수 있습니다. 문제는 출발점이 아니며 문제는 정수가 보유 할 수있는 최대 값입니다. 문제를 완화하는 유일한 방법은 64 비트 정수로 업그레이드하는 것입니다.
(내가 방금 깨달은 것) : 1970은 0으로 설정되었으므로 시간 내에 다시 도달 할 수 있습니다. (1901 년으로 돌아 가면 당시로서는 충분했다). 그들이 서명되지 않았다면, 그 기원은 1901 년에 1970 년부터 다시 시작될 수 있었을 것이며, 우리는 다시 같은 문제를 겪을 것입니다.
모든 시스템이 "과거"및 "미래"값만을 처리해야하는 것은 아니기 때문에. 유닉스가 만들어지고 시간 시스템이 정의 된 70 년대에도 그들은 60 년대 이전의 날짜를 처리해야했습니다. 그래서 부호있는 정수가 의미가 있습니다.
모두가 64 비트 time_t로 전환하면 우리는 2020 년 또는 그 이상의 136 년 동안 y2038k 유형 문제에 대해 걱정할 필요가 없습니다.
부호없는 값을 사용할 때보 다 근본적인 문제가 있습니다. 부호없는 값을 사용하면 시간을 한 번 더 가져옵니다. 이것은 확실히 긍정적 인 영향을 미칠 것입니다 - 우리가 지킬 수있는 시간을 두 배로 늘릴 것입니다 -하지만 나중에는 나중에 문제가 발생할 것입니다. 일반적으로 고정 된 정수 값의 경우이 선들에 문제가 있습니다.
UNIX가 1970 년대에 개발 될 때, 60 년 시계가 괜찮 았지만, 분명히 120 년 시계가 더 좋았을 것입니다. 그들이 더 많은 비트를 사용했다면, 우리는 훨씬 더 긴 시계, 즉 1000 년을 보냈지 만, 그렇게 많은 시간이 지나면 우리는 똑같은 묶음으로 돌아 왔을 것입니다. 아마도 " 더 많은 비트를 사용합니까? "
그런 식으로 작성한 사람이 자신의 문제가 아닐 수도 있으므로 알고 계셨습니까? ;) –