언제가 될지 기약은 없지만 간혹 생각나면
아래 URL 에서 최신 버전 확인해 보시길 바랍니다.

http://ftp.linuxchannel.net/devel/php_calendar/  <-- 기본
base
http://ftp.linuxchannel.net/devel/php_solar/
http://ftp.linuxchannel.net/devel/php_lunar/

개인적으로 행성의 위치계산까지 바라보고 있는데 이건 너무
힘들것 같아서 포기..


[인철]님이 남기신 글:

>우선 답변에 감사드립니다.
>
>홈페이지를 만들면서 기존에 db로 구축되어 있는
자료를
>최대한 부하를 감소해보고자 계산으로 바꿔 처리해볼려
했었는데,
>
>-_-;; 배보다 배꼽이 더 큰격이 되버려서 
>
>다시 기존 db 잘 다듬고 인덱스 설정 잘해서 쓰는걸루
돌아갔습니다.
>
>어쨌건 , 성실하고 친절한 답변에 다시 한번
감사드립니다.
>
>----------------------------------------------------------------------------
>저의 상황 및 테스트 결과입니다.
>----------------------------------------------------------------------------
>음/양력 및 절입시간, 및 공휴일 , 28수 등등 기타 역관련 db
데이터가
>약 150메가 가량..
>
>150메가 분량을
>현재로선 2038년도까지 이지만 현재 산이님의
소스로도
>파일 단 한개로 교체가 가능합니다.
>
>정말로 대단한 성과 이긴 한데 , 성능적으로는 좀 힘드네요.
웹용이라...
>
>db 자료나 산이님 소스나 년도 제한은 있습니다.
>계산 능력이 db 자료를 능가하지 않고서는 굳이 성능적인
효율을 감소해야 할 
>필요성이 없어져 db 자료 좀더 다듬어 보기로
했습니다.
>
>다시한번 친철한 답변에 감사드리며, 복받으세요
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>[산이]님이 남기신 글:
>
>>우선 음양력 변환은 좀더 검토해봐야 할것 같습니다.
>>기존 unix_timestamp 기반은 JD 기반으로 바꾸어서 계산해야
하는데 이건 만만치 않은 작업입니다.
>>
>>그리고 24절기 계산에서
>>
>>http://gapja.net/test/index.php
>>
>>은 오류가 좀 있네요. 예를 들어 0년은 2000년으로
표기되네요.
>>
>>class.calendar.php 의 _mktime(), _date() 함수를 이용해서 바꾸어 놓은
것이 있는데
>>
>>http://linuxchannel.net/?vhost=phps&php[src]=%2Ffunc%2Fclass.calenda
r.ph
>>http://linuxchannel.net/?vhost=phps&php[src]=%2Ffunc%2Fclass.solar.p
h
>>
>>demo 는
>>
>>http://linuxchannel.net/gaggle/solar.php
>>
>>입니다.
>>
>>음양력 변환은 좀더 시간이 걸릴듯...
>>
>>그리고 기본적으로 JD 구하는 공식에 약간 문제가 있는듯
합니다.
>>
>>-4712-01-01 12:00:00 (UTC) == -4712-01-01 21:00:00 (KST)
>>
>>이 날짜를 대입하면 JD 0.0 이 나와야 하는데 다른 수치가
나오네요
>>
>>
>>[인철]님이 남기신 글:
>>
>>>kldp 에서 검색하는 유저수준일뿐 활동해본적은
없습니다.
>>>
>>>취미로 PHP 를 공부하는 수준입니다.
>>>php 스쿨에서 포팅하신글을 보게 되었습니다.
>>>
>>>실은 역학관련 프로그램을 만드는과정에서
 본문서를 접하게 되었습니다.
>>>윈도용으로 개인적으로 사용하는 역술프로그램을
 인터넷용으로만들어서

>>>같이 사용하고 커뮤니티할수있는
 사이트를 만들어보려고요..

>>>
>>>기존에는 db로 되어 있는 음양력데이터와
 절기일 데이터를 이용해서
>>>db에서 접속해서 가져오는 형태였기에 .. ( db 데이터가
100메가가 넘습니다 -_-)
>>>db 자료라 이것저것 여러가지가 포함되어 있는
자료지만,
>>>
>>>음,양력 변환과 24절입시간만 계산으로 처리가 되면 웬만한건
다 해결되거든요..

>>>산이님께서 올리신문서를 바탕으로 하게되면 파일한개로
처리가 가능해져서요..

>>>
>>>db 데이터와 비교를 해보면 , 절입시간이 약 5~30분가량 차이가
나긴하지만요..

>>>지나온년도를
 비교해서 평균적으로 느리거나 , 적게 나오는지
판단해서
>>>일반적으로 많이 사용되는 시간을 기준으로 가감해서
출력하면 문제 없다 보여집니다.
>>>
>>>
>>>----------------------------------------------------------------------
>>>
>>>사실 산이님 소스를 봐도 저역시, 천문학에 문외한이라
설명문서 읽어봐도
>>>먼소린지 모르겠습니다.
>>>다만, 프로그래밍 언어적 구문이해로 문맥의 흐름을 따라서
가보는정도입니다.

>>>
>>>소스를 보건데,
>>>
>>>>위의 2개의 파일은 내부 기본 로직은 unix_timestamp
입니다.
>>>>따라서 Unix/Linux 에서는 1901 ~ 2038 까지만 가능합니다(32
bits).
>>>
>>>제가 첨부한 파일이 unix_timestamp 의 2038 제한을 넘어 가능하게
해주는 lib 입니다.
>>>
>>>
>>>class.solar.php 이부분은 제 게시물의 첨부파일을 이용해서

>>>3000년(?)까지의
 계산이 되도록 수정되었습니다.

>>>
>>>단순히 class.solar.php 에 사용된 명령어 중에
>>>date , gmdate , mktime 함수를 
>>>adodb_date, adodb_gmdate, adodb_mktime 으로 
>>>첨부된 파일의 함수로 대체하는것이 전부입니다.
>>>
>>>http://gapja.net/test/index.php (2038년도 이후도
출력됩니다.)
>>>
>>>class.lunar.php 파일역시 수정하여서 음양력 부분만 빼고는
계산이 됩니다
>>>음양력 부분은 
>>>&_newmoon,&_fullmoon,&tolunar 함수에 지정된 배열값때문에
그런듯보입니다.

>>>특정 년도까지만 값이 지정되어 있습니다.
>>>(아마도 작성할때 2038 제한때문에 그래놓으신듯)
>>>
>>>static $unit = 5665; // see above comments
>>>static $ffx = array(
>>>	19310517=>2640, 19321030=>-840, 19341008=> 840, 19530612=>-600,
>>>	19550222=>4020, 19580218=>2700, 19860311=>-540, 19950727=>1140,
>>>	20120619=> 780, 20150815=>-540, 20170226=> 480, 20350109=> 540,
>>>	);
>>>
>>>static $unit = 5665; // see above comments
>>>static $ffx = array(
>>>	19031006=>2000, 19131213=>  120, 19280801=>2100, 19360506=> 400,
>>>	19380712=> 300, 19450625=>  600, 19500828=>-700, 19550308=>2700,
>>>	19560524=>1900, 19581027=> 3000, 19810617=> 500, 19990501=>-900,
>>>	20211021=>-300, 20261125=>-1100, 20280210=> 700, 20320425=> 600,
>>>	);
>>>
>>>
>>>static $notminus = array(19651024=>1); // do not minus
>>>static $notleap =
array(1965925=>1,1985121=>1,1985220=>1,20331222=>1,2034219=>1);
>>>static $dominus =
array(1985121=>1,1985220=>1,20331222=>1,2034219=>1);
>>>
>>>
>>>이부분을 입력된 년도를 기준으로 계산하는방식이
 되면 특별히 쥴리어스력으로

>>>전체 소스구조가 바뀌지 않아도 가능해보이긴합니다만
 .. 제가 멀 알아야죠 -_-;;
>>>
>>>해당 함수에 지정되어 있는 배열값의 년도뒤에 날짜인거
같은데 
>>>이게 무슨 날짜인지 왜 저 날짜가 되어 있는지
모르겠네요..
>>>
>>>저부분도 계산으로 처리하는 방식만 되면 무난히 음양력도
2038년 제한을 넘어 가능해질듯 보여집니다.
>>>
>>>(현재 프로그램의 정확도를 떠나서 기간제한을 넘어
실행가능한 수준의 의미로요..)
>>>
>>>
>>>
>>>빠른 답변, 감사드립니다. ^^;
>>>
>>>
>>>ps : 
>>>문외한으로서
 답하는거니 어처구니 없어도 이해해주세요..

>>>음양력이나 별다른 결과가 동하지 않는
달력으로서는
>>>
>>>아무런 계산없이 단순 for 방식만으로 무한으로 가능하지
않나 싶은데요??
>>>물론 천문적인 계산방식이 아닌 단순 알고리즘
개념으로요.
>>>
>>>단순히 해당 월이 30일인지 31일인지만 알면 양력달력으로는
 무한이 가능할듯 싶습니다.
>>>
>>>천년단위로 각1월이 30일인지와 윤년이 몇번째 인지만 배열로
정해놓으면 될듯싶은데요.
>>>
>>>그리고 그정보를 바탕으로 for 돌리면 양력 달력은 무한
출력이 되지 않을까 
>>>
>>>가벼운 생각해봅니다 -_-;;
>>>
>>>
>>>
>>>[산이]님이 남기신 글:
>>>
>>>>[인철]님이 남기신 글:
>>>>
>>>>>-----------------------------------------
>>>>>답변자가 기본적으로 참고할 내용입니다.
>>>>>- 배포판(옵션)    : 
>>>>>- 커널버전(옵션)
  : 
>>>>>- 데몬버전(예:apache
 1.3.27) : 
>>>>>- 데몬설치유형(RPM/컴파일/기타)
 : 
>>>>>-----------------------------------------
>>>>>*스팸필터링:한글
 4자(8개 문자) 이상 없으면 스팸페이지로 이동합니다.
>>>>>
>>>>>
>>>>>http://linuxchannel.net/docs/lunar.txt
>>>>>글을 읽고 소스도 보았습니다.
>>>>>
>>>>>32bit 정수 자릿수 문제때문에 mktime 제한 때문에 2038년으로
제한 하신거 같습니다.
>>>>>
>>>>>첨부한 파일을 include 하고 나서
>>>>>
>>>>>class.solar.php 
>>>>>class.lunar.php 소스내용중 해당 php 명령을 교체하면
>>>>>
>>>>>제한을 넘어서 가능해집니다.
>>>>>
>>>>>양력 > 음력 변환에서 입력한 년도가 안되는군요..
>>>>>2038 이하의 년도만 음력 변환이 됩니다.
>>>>>절기는 2038년 이후도 잘 표시됩니다.
>>>>>음력변환부분에
 고정이 된거 같습니다.
>>>>>
>>>>
>>>>위의 2개의 파일은 내부 기본 로직은 unix_timestamp
입니다.
>>>>따라서 Unix/Linux 에서는 1901 ~ 2038 까지만 가능합니다(32
bits).
>>>>
>>>>이것을 확장가능하게 끔 하려면
>>>>
>>>>http://ftp.linuxchannel.net/devel/php_calendar/class.calendar.php
>>>>(이건 달력인데 먼 과거나 먼 미래까지 표시됩니다, 음-양력
변환 없음)
>>>>
>>>>이것처럼 unix_timestamp 을 완전히 버리고 JD(Julian day)로 그 기본
로직을 바꿔야합니다.
>>>>
>>>>그런데
>>>>음력<->양력
 변환은 원론적인 설명부터 해야하는데...
>>>>
>>>>우선 태양 - 지구 - 달이라는 천체의 운행(역학)에 기반을
두고 있습니다.
>>>>때문에 역학에 대해서 아주 전문적인 지식없이 구현하기가
상당히 어렵습니다.
>>>>
>>>>또한 정해진 공식도 없고, 정확한 태양 - 지구 - 달의 위치를
계산하기 위해서는 미해군 슈퍼컴퓨터로 계산하고 있다고
합니다. 우리는(한국 천문연구원) 이 data 를 받아서 달력을
만든다고 합니다.
>>>>
>>>>그리고 또한 천체의 위치계산시 중요한 data 변수가 있는
"delta T"가 바로 그것입니다. 이는 오르지 관측을
통해서만 그 값을 구할 수 있다고 합니다.
>>>>
>>>>따라서 먼 미래의 음력<->양력 변환은 사실 그 의미가
없습니다. 즉 delta T 때문이죠.
>>>>(변환한다고
 해도 틀릴 확률이 매우 높음)
>>>>
>>>>여차여차 해서 제가 만들어 놓은 것은 원리를 깨우쳐가면서
안돌아가는 머리로 겨우 근사식으로 짜놓은 것이고 오차
때문에 날짜 보정해 놓은 것입니다.
>>>>
>>>>만약
>>>>
>>>>위의 2개의 class를 unix_timestamp 가 아닌 JD를 기반한 로직으로
수정하면 어찌되었든 음력<->양력 변환은
가능합니다.
>>>>
>>>>그런데 오차가 상당히 심하기 때문에 별 신뢰성이
없습니다.
>>>>
>>>>이것을 수정할려고 올초에 작심했다가 그만뒀습니다. 당시
너무 힘들게 코딩했기 때문에 수정하려면 머리털 다 뽑힐까
봐서... :)
>>>>
>>>>
>>>>
>>>>>또한 2038을 한계로 잡고 절기 간격을 평균을 정해놓으셔서
괜찮았는데..
>>>>>
>>>>>3000년이상 넘어가면 기준으로 잡힌 년도와 멀어져서 점점
간격이 벌어지네요..
>>>>>
>>>>
>>>>이건 앞서 얘기했듯이 delta T 또는 근사식때문에 어찌할
방법이 없습니다.
>>>>(미해군 슈퍼컴퓨터를 크래킹하지 않고서는 ㅠㅠ)
>>>>
>>>>
>>>>>입력한 년도를 기준으로 - 50년치를 자동으로
절기간격평균을
 재설정해서 처리하면 조금 나아질까요??
>>>>>
>>>>
>>>>획기적인 방법이나 계산식을 누가 만들지 않고서는
힘들겁니다. 천문학 전공한 사람이라면 아마 가능할지도...(전
 천문학 근처도 가보질 않아서 ㅠㅠ)
>>>>
>>>>JD2000.0 기준이기 때문에 앞뒤 100년 정도가 비교적 맞고 그
범위를 넘어서면 상당히 틀어집니다.
>>>>
>>>>평균치 계산법은 구글에서 "진짜만세력"
 검색해보면 참고가 될듯합니다.
>>>>(아마 소스가 있을 듯)
>>>>
>>>>
>>>>
>>>>>문외한이라
 생각나는게 별루 없네요..
>>>>>
>>>>>
>>>>>
>>>>>어느부분을
 수정해야 하는지 알고 싶습니다.
>>>>>
>>>>>가능하면 첨부 파일을 이용하여 수정된 소스를 바라면 너무
욕심일까요 -_-;;
>>>>>
>>>>
>>>>unix_timestamp -> JD 기반으로 언젠가 고쳐야하는데
ㅠㅠ
>>>>...
>>>>
>>>>첨부한 ADOdb 는 외국사람이 만든것 같은데 맞나요?
>>>>이건 음력<->양력 변환은 없네요.
>>>>
>>>>http://ftp.linuxchannel.net/devel/php_calendar/
>>>>이것과 비슷해 보입니다.
>>>>
>>>>
>>>>참고로,
>>>>
>>>>http://ftp.linuxchannel.net/devel/php_solar/
>>>>http://ftp.linuxchannel.net/devel/php_lunar/
>>>>http://ftp.linuxchannel.net/devel/php_calendar/
>>>>
>>>>
>>>>php_solar 는 태양의 위치, 절기, 일출 계산, 별자리계산
등등
>>>>php_lunar 는 음력<->양력 변환, 일월식, 별자리 등등
>>>>php_calendar 는 달력과 날짜 표시(먼 과거, 미래
표시가능)
>>>>
>>>>그리고 각 소스위 코멘중에서 [demo] 나 [docs] 링크 따라가면
해당 내용을 볼 수 있습니다.
>>>>
>>>>그런데 혹시 kldp 에 활동하고 계신분인가요?
>>>>어떻게 해서 이런것에 관심을 가지게 되었는지 여쭈어보고
싶네요.
>>>>
>>>>
>>>>>읽어봐주셔서
 감사드립니다. 
>>>>
>>>>======================================== 
>>>
>>>======================================== 
>>
>>======================================== 
>
>======================================== 

========================================