LunarCalendarBug

From KBase

Jump to: navigation, search

__원문__ : http://www.scgyong.net/prog.php?num=5#num5

예전에 음력 관련 코딩을 할 때 인터넷을 뒤져서 찾은 코드로 JScript 코딩도 하고 C 코딩도 하고 PHP 로도 포팅을 했었다. 그런데 알아보니 이 음력 변환 소스에 버그가 있었다.

음력(태음태양력)은 19년에 7번의 윤달을 넣는 방법으로 계절을 쫒아 가는데, 이것이 일정한 규칙이 없다. 어찌어찌 자료를 찾다 보니 계산법을 통해 대략적인 날짜를 구하는 공식을 찾았지만, 이것은 오차가 있는 계산법이다. 그래서, 현재 음력 날짜를 구하기 위하여 사용되는 코드는 모두 매 달마다 큰달(30일)/작은달(29일)의 정보와 어느 달이 윤달인지 저장하는 방법을 사용한다.

뉴스검색을 해 보니, 이 DB 에 문제가 있었던 모양이다. 그래서 작년에 한번 기사가 난 것 같은데, 2004년 11월 15일이 음력 10월 3일이라고 나오는 코드는 잘못된 DB 를 바탕으로 한 코드이다. 10월 4일이 맞다. 주위에 있는 폰들을 다 알아보니 제대로 나오는 폰이 절반 정도 된다.

또, 2006년 설날이 1월 30일(월)로 나오는 코드도 오류다. 1월 29일(일)이 맞다. 내년 설 연휴를 알아보는 사람이 생기면서 이 문제도 조만간 터질 조짐이다. 내년 설이 정확히 나오는 폰은 딱 한 개였고, 모두 월요일이 설날인 것으로 나왔다.

우리 회사에서 Application 을 만드는 JINOS 폰 (일명 !CanU 시리즈) 은 작년에 이 버그를 알고 모두 패치 했다고 한다. (나는 아직 패치를 받지 못해서 아직 버그가 있다) 그리고, 지금 개발중인 (JINOS 가 아닌) 프로젝트에서도 업데이트된 버전을 써서 개발을 진행하고 있다.

불만인 것은, 이게 DB 를 바탕으로 하고 있다 보니 소스의 데이터 부분이 참 길다는 거다. 윤달이고 아니고 하는 정보를 기억하는 정도일 뿐인데 달마다 하나의 바이트(혹은 그 이상)씩을 차지하고 있다. 게다가 더 불만인 것은, 양/음 변환 부분인데, 계산 첫 날을 정해 놓고 그 날 이후 지금까지 흐른 날 수를 센 뒤에, 그 날만큼을 다시 음력 날짜에 더하는 방법을 사용한다. JINOS 에 사용된 소스는 약간 더 똑똑한데, 이것은 매 해 며칠인지까지 기억해 두어서, 매 달을 계산하지 않아도 되게 했다.

__계속__ : NewLunarCalendar

Personal tools
Wiki Help (mediawiki.org)