天合历延续了中华传统历法核心思想，尤其是将朔望月与回归年相调和，定朔望和二十四节气，以中气定月序的思想观念及无中置闰规则等。结合现代天文观测技术对日、地、月及太阳系内大天体在宇宙中运行轨迹的精确拟合，直接计算所需星体在时间轴上运行至发生特定相对关系的空间位置所处的系列时间组合。使用基于东经120°平太阳时间的定朔定气数据，采用新法排月，以历月的“对应关系中气”确定月份，雨水为正月，春分为二月，……，冬至为十一月，大寒为十二月，无“对应关系中气”的历月为闰月。一般情况下，每个历月所含的中气就是这个月的对应关系中气，特殊情况如双中气月则第二个中气为其对应关系中气，双中气月前面的历月则以该月后面第一个中气为其对应关系中气。
        天合历完善了中气定月序思想及无中置闰规则使其适用于定气，并简化了判定月份名称的方法，不需要计算整年的天文数据，也不需要历算年起点。将现行的“冬至到冬至整年定月法”改为“节气定月法”，从根本上解决了现行农历中出现的诸如1700年、1852年只含惊蛰和春分的月份定为正月，1833年、1985年以及2053、2167、2205年只含立春和雨水的月份定为十二月等此类月份与节气对应不直观的问题。

        天合历JS版V3.14，欢迎试用。

下载信息  [文件大小：   下载次数： ]

点击浏览该文件:thl314.rar

此主题相关图片如下：thl101.jpg

V1.03  增加时辰干支。

下载信息  [文件大小：   下载次数： ]

点击浏览该文件:thl103.rar

V1.04版：增加命理用日干支时干支。

下载信息  [文件大小：   下载次数： ]

点击浏览该文件:thl104.rar

V2.04版：增加公历月主显功能。

下载信息  [文件大小：   下载次数： ]

点击浏览该文件:thl204.rar

V2.05版：增加公历月主显界面相关内容。

下载信息  [文件大小：   下载次数： ]

点击浏览该文件:thl205.rar

V2.06版：完善公历月主显界面内容。

下载信息  [文件大小：   下载次数： ]

点击浏览该文件:thl206.rar

    “节气定月法”与现行农历的“岁首定月法”没有实质性的忧点，同样也是一个中气没办法固定在一个月里；“节气定月法”排出的日历与现行农历排出的日历大同小异，看不出有什么实质优点，从实用上看，倒是排谱规则更繁琐。现行农历的优点是排谱规则简洁明了。从推算方面上也同样没有优点。凡是注重天象的历法如果要同时注重太阳和月亮，是没有绝对优点的历法。

    现行农历古人把冬至定在子月有2个因素，

1、便于观测。阴阳合历的农历定太阳回归点在几月几日左右是办不到，所以只好定太阳回归点在几月。

2、祭祀，古人很注重冬节祭祀，把子月定性为祭祀月，子为地支之首，他们定子月为岁首；别的中气充许上下月漂移，就是冬至古人不能接受在上下月漂移。当然也有点以一不变应万变的道理；有点象公历把太阳到黄经点0度即太阳过春分点要落在公历3月21日左右漂移。其实西方这样定是与复活节有关。

节气定月法与现行农历相比，至少有如下优点：
1、排历谱更加便利
现行农历由于采用“岁首起月法”定月份，排历谱时需要计算长达2-3年的太阳表和太阴表。而“节气定月法”月份由所含节气确定，不再预先以某一特定节气为基准，无需计算整年的节气数据，因而更加简便。
2、机器程序代码更加简洁
节气定月法确定月份时对任何中气都采用同样的标准，逻辑判断更加简化，软件程序更加简洁，所需数据减少，所需计算也更少。
3、历谱月份与节气对应更加直观
中气和月份之间没有全部一一对应的关系，这是使用定气法的必然结果，无可厚非。节气定月法与现行农历中月份与中气不一致的数量大体相当，两种方法没有优劣差别。但是，现行农历由于采用“岁首起月法”定月份，导致个别月份与节气对应不直观，如十二月只含立春和雨水两个正月节气、正月只含惊蛰和春分两个二月节气，随着地球近日点的循环，将来还会出现二月只含清明和谷雨、三月只含立夏和小满、四月只含芒种和夏至、五月只含小暑和大暑等情况。而节气定月法则完全消除了这些现象，使月份与节气对应更直观。

  1、排历谱更加便利简便。不是事实。

“节气定月法”规则更繁锁，规则更不好记，那么一大编跟“八股文”似的。不象现行农历规则，定一个冬至所在月不变其它节气不管、规则简洁明了。编程方面同样也是要计算几个月才能确定月序。“岁首起月法”定月份，排历谱时需要计算长达2-3年的太阳表和太阴表，这就看各人编程思路了，一年排谱我只让程序计算3个冬至日的所在朔月号。第1个冬至日到2个冬至日如果有13个月才在这13个月中找无中气的月号，条件不符合不找。第2个冬至日到第3个冬至日如果有13个月，找头2个月中是否有无中气、后面月份下年再说，条件不符合不找。以下代码和你的对比一下，你就会发现差不了多少。代码例子：

  function zqmo(y,n){//y年每个节气日所在月到1900年,1,1总月数(闰月未扣除)冬至n=24，y=年（用天文记年，公元前1年为0）

  var dtt=floor(S(y,n));var ykda=(erJD(y,1,1))-1;var jeJDc=dtt+ykda*1;
  var lumta=lunData(jeJDc,5);var dzrs=lumta;
  return dzrs;
   }

  function leapom(y){//无中置闰

   var lnmsj="";
  var n0=24*(y-1-1999)-6+24;var n1=24*(y-1999)-6+24;var n2=24*(y+1-1999)-6+24;
  var jav="",jbv="",jcv="",jqav="",jqav2="";
  var mtk=zqmo(y-1,24);//上年冬至日所在有效月
  var mwk=zqmo(y,24);//今年冬至日所在有效月
  var mek=zqmo(y+1,24);//明年冬至所在有效月
  var mxk=mwk-mtk; //计算两个冬至日之间有几个月。

  var myk=mek-mwk;
  if(mxk==13||myk==13){
  for(var jq=n0;jq<=n1+4;jq+=2){
  var jqka=jqdmo(jq);
  var jqkb=jqdmo(jq+2);
  var lnmsjb=((jqka-mtk+11+11)%12+1)*1;//计算月序，冬至日所在月为子月，化子月为11（初一0点为月起点），它月不管节气。
  var lnmsja=lnmsjb;
  var unmca=jqkb-jqka;
  if(lnmsjb==10)lnmsja="a";
  if(lnmsjb==11&&myk==13)lnmsja="b";
  if(lnmsjb==11&&mxk==13)lnmsja=0;
  if(lnmsjb==12&&myk==13)lnmsja="c";
  if(lnmsjb==12&&mxk==13)lnmsja=0;
  if(unmca==2&&mxk==13)lnmsj+=lnmsja+","+0+","+0+",";
  if(unmca==2&&lnmsjb==11&&myk==13)lnmsj+=lnmsja+","+0+","+0+"";
  if(unmca==2&&lnmsjb==12&&myk==13)lnmsj+=lnmsja+","+0+","+0+"";
  }
  }else{
  lnmsj=0+","+0+","+0;
  }
  var va=lnmsj;if(lnmsj=="")va=0+","+0+","+0;
  var vv=va.substring(0,1);
  var vo=vv;
  if(vv=="a")vo=10;
  if(vv=="b")vo=11;
  if(vv=="c")vo=12;
  return vo;
  }

 2、机器程序代码更加简洁所需数据减少更是不可能，只要是要求定气定朔同样也是要用到星历表。减少是不可能的。我所写的程序，单只计算农历的不到500kb（含星历表的哦），

3、历谱月份与节气对应更加直观，是你一家之说，其实两个规则排出的结果只有少数不同，1984年10月到1985年2月有不同后，再到如2033年11月到2034年2月之间才不同而于。几十年才这么几个月不同。采用繁锁规则不现实。

    另：一个万年历程序最重要的是实用，一个与现行日历不同的程序一点实用性也没有。还有凡是注重天象的历法如果要同时注重太阳和月亮，是没有绝对优点的历法。直不直观其实各人看法不同，意建也是不同的。再说农历规则要不要改我们用不着操心的。反正日子都是一天一天的过，用哪种历法都一样过日子。用农历现在只是传统文化了，如：元宵节、中秋节等等。

一个置闰规则都这么长，计算冬至都要第1个、第2个、第3个，参数算过去代过来，连字符比较都夹杂了，比节气定月法烦琐多了。用节气定月法就不需要这么多，当以节气、中气各在其位，月份就自然确定了。此贴上传的使用节气定月法的软件里面包含3套节气定月农历、1套现行农历、1套共用的星历表、1套各种天象的计算程序，一共不足500KB。除去星历函数和界面设计语句，用于计算历谱的代码没有几行。

例如：计算2014年农历2月的历谱
1、计算今年春分日。已知太阳视黄经求时间，得儒略日数d0=2456738。
2、计算包含春分日的历月。已知月日经差求时间，得朔日d1=2456718，下一个朔日d2=2456748。
3、计算该月其余节气日。已知黄经求时间，得惊蛰日d3=2456723。
4、确定月份。包含惊蛰和春分，为2月。d2-d1=30，d3-d1=5，d0-d1=20，即该月大，初六惊蛰日，二十一日春分。（如需时分秒时间就保留小数部分）
如需与公历对照，将儒略日数换成公历就行了。得：初一公历3月1号、初二3月2号、初三3月3号......

      置闰规则都这么长，是哪个规则长，先来比一下：

      现行“岁首起月法”定月置闰规则：

     上年冬至日到今年冬至日如果有13个月，以第1个无中气月为闰月，在那个月之后称闰几月，如在三月后是第1个无中据月就称闰3月。

      你的“节气定月法”定月置闰规则：

    立春  位于  正月①位  或  正月②位  或  正月前一个月的末位（即闰十二月或十二月的末位）
    雨水  位于  正月①位  或  正月②位  或  正月②位之后的第一位（即正月③位或二月①位）
    惊蛰  位于  二月①位  或  二月②位  或  二月前一个月的末位（即闰正月或正月的末位）
    春分  位于  二月①位  或  二月②位  或  二月②位之后的第一位（即二月③位或三月①位）
    清明  位于  三月①位  或  三月②位  或  三月前一个月的末位（即闰二月或二月的末位）
    谷雨  位于  三月①位  或  三月②位  或  三月②位之后的第一位（即三月③位或四月①位）
    立夏  位于  四月①位  或  四月②位  或  四月前一个月的末位（即闰三月或三月的末位）
    小满  位于  四月①位  或  四月②位  或  四月②位之后的第一位（即四月③位或五月①位）
    芒种  位于  五月①位  或  五月②位  或  五月前一个月的末位（即闰四月或四月的末位）
    你的“节气定月法”定月置闰规则还有一半我没贴出来呢！规则谁更长。你自已比比？

    排谱方面，现行的只要注意一下两个冬至日之间是不是有13个月，如有才去找第一个无中气月，不必去理会节的位置，定冬至日在11月，相当定冬至点为回归年点，这与公历定春分点一样，定点在日左右是办不到，只能定点在一个月里。你的规则却必须24个节气全部注意，一个也不能不管，但又没办法做定一个点不变，每个多是要在两个月之间漂移，一个定点也没有，定点在日左右是办不到，你的定点在一个月里你也办不到。

     比编程代码长短其实一点意义也没有，我上面的代码只是个算法举例；因为各人思路不同，同一规则不同的人编出来的源码也是长短不同的。就是同一个人，随着经验增长，代码会越来越短。

     两个规则排出的结果只有少数不同，1984年10月到1985年2月有不同后，再到如2033年11月到2034年2月之间才不同而于。几十年才这么几个月不同。采用繁锁规则不现实。