10000년 문제

10000년 문제(一萬年 問題, Year 10,000 problem, Y10K, deca-millennium bug)는 2000년 문제와 비슷하게, 연도가 다섯자리가 되는 10000년 1월 1일 이후의 날짜나 시각을 다루는 과정에서 오류가 발생하는 문제이다. 2000년 문제가 Y2K라 불렸듯이, 흔히 10000년 문제를 Y10KYAK(10을 16진수로 나타냄), YXK(10을 로마 숫자로 나타냄) 등으로 줄여 부르기도 한다.

2000년 문제가 발생하기 이전에는 연도를 다루는 많은 수의 소프트웨어들이 연도의 마지막 두 자리만을 저장하고 보여 줄 때 앞에 ‘19’를 덧붙였기 때문에, 2000년이 1900년, 19100년, 100년 등으로 표시되는 경우가 많았다. 마찬가지로 마이크로소프트 엑셀과 같은 여러 소프트웨어들은 연도를 마지막 네 자리만 표시하므로 10000년을 0000년으로 표시할 것이며, 몇몇은 아예 다섯 자리 이상의 연도를 입력할 수 없기 때문에 문제가 발생할 것이다.[1] 그러나 2진법 체계에서는 10000년이 특별한 의미를 지니지는 않기 때문에 내부적인 표현에는 문제가 없을 수도 있다. (예를 들어 엑셀의 경우 날짜를 1899년 12월 31일 이후 지난 날의 수로 저장하는데, 여기에 따르면 9999년 12월 31일은 2958465로 표시되며[2] 이 숫자를 넘는다고 해서 오버플로가 발생할 가능성은 적다.)

롱 나우 재단은 10000년 문제를 피하기 위해서 02000년 같이 연도를 다섯 자리로 적는 방법을 시도하고 있다. 하지만 이 방법은 100000년 문제에는 소용이 없으며, 만약 네 자리 연도 앞에 0을 채워 넣지 않을 경우 사전순 정렬에서 문제가 생길 수 있다.[3] 1999년에 발표된 RFC 2550에서는 앞으로의 어떤 날짜도 문제 없이 사전 순으로 표현할 수 있는 방법을 다루고 있으나, 실제로는 해마다 발표되는 만우절 RFC였다.[4]

같이 보기

[편집]

각주

[편집]
  1. 시스템 자체는 10000년 이후에도 정상적으로 시간을 인식하지만, explore.exe를 중심으로 문제가 일어난다.
  2. 대표적으로 DATETIME 개체의 경우, 9999-12-31 23:59:59가 최댓값이다.
  3. 예를 들어 10000년이 1000년과 1001년 사이에 나타날 것이다. 실제로 비슷한 문제인 10억 초 문제2001년 9월 9일 01:46:40 UTC에 발생한 바가 있다.
  4. RFC 2550 - Y10K and Beyond. 여전히 여기서 다룬 방법들은 잠재적으로는 유용하다.