45억년이라는 시간 계산은 아마도 일반인들이 이해하기 쉽게 초단위를 그래고리력으로 끊어서 계산한것이 아닐까 싶다.
자전/공전 주기의 변화를 조금 세밀하게 적용해서 계산한다면 나이가 훨씬 늘어나지 않을까 싶다.
(한 10억년 전후 쯔음이 되지 않나 싶지만)
20억년 전 선 캄브리아기에는 하루는 13시간 이었다고 한다.
10억년 전에는 약 19~20시간으로 추정되고.
현재 지구의 자전 속도는 10만년에 2초 정도 감소한다.
예전에 엑셀 시간/날짜 함수들을 전부다 C언어로 포팅하는 뻘짓을 하면서 느낀게
만년 달력이상은 무쓸모 겠구나.라는 생각을 하게됨.
이형님 현자타임?
태양이 나빴네
달(충돌전 가이아)이 지구를 때리고 난 이후에 달의 영향으로도 많이 바뀐 탓이 크지 싶네.
이분 달력과 태양공전주기를 착각하시는분.
달력이 문제가 아니고 1년이 365일이 아니라는게 문제죠? 님 아직도 모르시는듯.
연대학을 공부해 보세유~
님이 말하는건 태양공전주기의 변화고, 연대학은 그것을 역사적으로 지역적으로 문화적으로 접근한 '서수' 개념일 뿐입니다~ 넘버링 자체엔 큰 의미가 없어요. 추적해 가는 과정에서의 순서가 의미있죠.
지구의 시간, 우주의 시간을 고려해 138억년을 커버하기 위해 -1000억년 ~ 4845억년을 표현할 수 있는 기간을 잡은거라. 님이 말하는건 이미 지식으로 갖고 작성한 코드입니당.
하루가 13시간이면 공전주기 증감소 차이를 배제하고 20억년전 1년과 지금의 1년은 몇백일 차이일까요? 그걸 그래고리력이나 율리우스력으로 표현한다? 그것도 초단위로? 그래고리력을 기준으로 보정까지 계산한 년단위 수식 몇 개면 될텐데요? 대체 뭘하면 년월일 시분초 단위까지 계산하는 타입이 필요한건가요?
그레고리나 율리우스력은 시간위에서의 특정 선형함수일 뿐입니다. 그걸 역사의 어딘가에서 차용할때, 상대 거리를 표현할 '기준' 이상의 의미는 없는 것이죠.
그래서 historical_date 라는 함수로 여러개의 선형함수를 합성할수 있게 작성해 놓은것이구요.
그레고리력 역법으로 대략의 시간 계산하는것은 타당하다 싶어도. 세밀한 시각을 표현하는것은 아니다 싶네요.
+- 무한대의 시간을 율리우스나 그레고리로 언급해도 아무 문제가 없다는거죠. 그 시점은 초 단위로 unique 할 뿐이니까요. 물론 태양의 공전주기랑은 안맞죠. 그거야 매일 매일도 다른거니 어차피 무관하다는거죠.
그럼 수식 몇개면 될걸 수천억년까지 계산하는 초단위 타입은 왜 만드신거?
그러니까 나는, 태양을 기준으로 한 지구의 정확한 위상을 표현하기 위해 날짜 타입을 만든게 아니란겁니다. 이해하셨죠?
시간 순으로 정렬하기 위한 데이타베이스를 만들기 위해서죠 : )
그걸 초단위로 정렬이 필요한 데이터가 있긴 있는가 보군요. ㅋㅋㅋㅋ
ㅇㅇ 넵. 광활한 데이타베이스가 될겁니다.
사실 코드를 보면 알겠지만 1/1000 초를 기준으로 할려고 설계했습니다. 근데 64비트로는 138억년을 커버할 방법이 없어서요.
와우~ 인빌리버블~뭔지 모르지만 굉장히 궁금하네요 ㅋㅋ
그렇다고 double 타입을 이용해서 소수점 위의 '일' 과 소수점 아래의 '시간' 으로 분리를 한다면, 연도 값이 커지면 일 정보가 날아가게 되어서 입력된 값과 다른값이 의도되지 않게 저장될 가능성이 있더군요. 그래서 rigid 한 정수기반 날짜타입을 원하게 된거죠. : )
막상 계산해보면 int64 가 double 보다 느리지만, '명확성' 을 높이길 원한겁니당~
세상에 공개될 가능성이 있는 프로젝트인건가요? 기사나 뭐 그런거를 통해서라도요.
대략의 힌트라도 주시면 좋으련만
넵~ 이건 end-user 가 일반인인지라.
암튼 어떤 프로젝트인지 공개의사는 없으신거 같으니 이만하도록 하져 ㅋㅋ
재밌는 프로젝트예유 : ) 아직 윤곽을 드러내기는 이른것 같아요.