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

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

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

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

  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月之间才不同而于。几十年才这么几个月不同。采用繁锁规则不现实。

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

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

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

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

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

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

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

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

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