我学着写了个万年历，在月历生成方面遇到个难题：按2个冬至之间是否只有12个朔来判断该不该置闰，2033年是不置闰的，而2034年要闰十一月的，但是这个闰十一月却是属于公历2033年的12月份22日的。当月历定位到2033年12月时，22日处并不显示闰十一月小，当日历定位到2034年1月时，才算出1至19日是闰十一月小。
说白了就是，我的算法是2033年时还未算出2033.12.22日是闰十一，而到2034年时才算出原来2033.12.22是闰十一月。这对于显示2033年12月份的月历来说，显然为时太晚。
我自己用了个愚蠢的办法是把公历闰十一月的年份找出来比如2033、2128、2147、2242……，当遇到这些年份时把本年的最后一个朔改为“闰十一月”，否则为“十二月”。
能否有更好的解决方案？在此希望能够得到“许兄”及各位高手的讲解、帮助！谢谢！

这个问题，看来只有等许兄有空时来解释时，我也洗耳恭听。

 

不过，在许兄回答之前，我胡说几句，请楼主别见怪。

 

我觉得推算中国的万年历，根本不必管公历的2033年还是2034年。

建议还是用儒略日来推算。推算之后再来换算。

如果推算的时间长度不大，比如只有二百年，那么就用365.2422作为固定的回归年，误差也不会太大。

为了避免公历的闰年造成的日期跳变。

每次推算时，可以前后各延伸一二天。

 

寿星万年历里，就是按中国天文历年来排历谱的。从冬至所在月开始排，一直到下一冬至月的前一个月。

但若要完整地排一个中国民用年的历谱，至少要推算三年（前后各一年）的天文历谱。仅仅推算一年的历谱是无法完整排民用历谱的（即万年历）。

所以楼主提到的问题，应当可以解决的。就是把数组元素扩大，不是12个，而36个。这样或许就没问题了。

请楼主试一下。

 

（寿星万年历的一个老版本，在武则天改周时段，年号的变更有时会出现小误差的。

后来许兄解释是：因为推算的时间段不够长。当他把推算的前后时间加长后，年号的变更就正常显示了。）

 

 

 

感谢楼上的“浪—淘—沙”兄！下面引用您的话：
1.不过，在许兄回答之前，我胡说几句，请楼主别见怪。
——浪兄热心回贴，句句言之有理，小弟怎会见怪？

2.建议还是用儒略日来推算。推算之后再来换算
——是的！我后面将尝试“儒略日”来推算。

3.但若要完整地排一个中国民用年的历谱，至少要推算三年（前后各一年）的天文历谱。仅仅推算一年的历谱是无法完整排民用历谱的（即万年历）。所以楼主提到的问题，应当可以解决的。就是把数组元素扩大，不是12个，而36个。这样或许就没问题了。
——是的！我起初也是想计算36个朔月时刻，这样的话就决对没有问题了！但是这无疑增加了程序计算时间，降低了程序响应速度。

通过刚才写程序时的观察，我发现：如果我计算出来的第13个朔时间是在“冬至2”的下一天的话，那么这个朔一定是“闰十一月”，否则这个朔为“腊月”。我目前用这样的办法来解决问题，这个判断是非常容易的，所以程序又变得简单了。我校对了2033到5886年，发现这个作法好象是可行的。
2033  2128  2147  2242  2614  2728  2910
3062  3244  3339  3616  3711  3730  3825
4007  4159  4197  4322  4341  4379  4417
4531  4599  4694  4713  4789  4808  4971
5085  5104  5161  5180  5199  5294  5305
5476  5677  5696  5772  5791  5848  5886
以上这些年份均在12月份里有个“闰十一月小”，它的前一天正是“冬至”，其它的年份还未去校对，不知这样的作法是否可以。

当校对到5905年12月时，发现以上作法是不行的。5924年的也不行。

你的判断方法不是通用的，但你在三千多年内都能正确判断出来。这也不仅仅是巧合的问题。

而是那一段时间，闰十二月的机会太少。

当春分点不断西移时，冬至点离近日点也越来越远。这时，闰十二月的机会就多起来了，你的判断方法这时就会经常出错了。

你上述提到的二个年都闰十二月，不是闰十一月（按你的算法是闰十一月）。

 

再过19年，5943年不闰，而是5944年闰二月。

公元5943年12月22日是冬至日。第二天是5943年12月23日，是农历的一个朔日。按你的算法，这个朔日开始月是闰十一月，但实际上并非如此。而是到了5944年3月21日（朔）开始的一个月才置闰（这个月也正好是第一个无中气月）。

 

是否一定要计算三个周年的历谱呢？这个问题还是请教许兄吧。

我觉得现在是建寅为正。不会计算三个周年的。只要计算二个周年就足够。

在建子为正时（唐武则天改为周历时），确实要计算三个周年，否则可能会出现年号变更的失误。（这个许兄已经在新版里修正过来了。）

 

你计算一个周年是无法保证你的算法是通用的。或者你在程序里加一个判断语句，在XXXX年前使用你的一个周年的计算方法。在XXXX年开始使用计算二个周年的算法。

用不同的算法试一下，看看哪个算法省时间，就选哪个。

“当春分点不断西移时，冬至点离近日点也越来越远。这时，闰十二月的机会就多起来了，你的判断方法这时就会经常出错了。”
——真知灼见！


“你计算一个周年是无法保证你的算法是通用的。或者你在程序里加一个判断语句，在XXXX年前使用你的一个周年的计算方法。在XXXX年开始使用计算二个周年的算法。用不同的算法试一下，看看哪个算法省时间，就选哪个。”
——很赞同您的思路！看来目前也只能这么一试。

闰其他月是没有问题的！
问题只是出现在“闰冬月”上，现在我的作法是：判断第2个冬月的下一个月是否包含“中气”不含的话为“闰冬月”否则为“腊月”，所以只是多算了一两个朔和中气，这样对速度基本不影响。只是怕“不该置闰冬月”时，却被我置了闰。因为有时没有中气的月也不是闰月。

翻了公元8000年及9000年后的几百年历,发现冬至后的一个月,如果只有"小寒"节气,那么肯定是闰月.

所以楼主的算法基本可以算是通用的.

 

我这么想的:如果冬至是十一月的晦(月末),那么从这冬至月开始的"年"肯定是超长的,一定有闰月的.若冬至月后第一个月仅仅只有小寒,肯定是要置闰的.

 

寿星万年历只能到9999年,再以后的年是不是符合这个规律,我不知道了.

 

至少要排算1年历谱，以及前1年的几个节气，以及后一年的几个节气，以及后一年的冬至。也就是说要3年的气朔数据，其中，中间这一年的数据是完整的。

一种比较简单的方法是，你就排3年完整历谱，中间这一年肯定是正确的。当然速度降了3倍。不过，你用的是VB，再慢也比javascript快。

我当时为了提速度，只算1年并外加几个必要的前后年节气，这种方法很容易出错，我当时在这个问题上错了很多次，好在大家用助调度。

我不建议你使用《寿星万年历》的排年谱方法，太复杂了，还是一次性排2年或3年吧。3年出问题的可能性最少，2年次之，1年非常危险。

V4.15版，只排1年并附加前后1年的部分气朔信息综合处理，

 

linkerson

先生的算法逻辑不错啊，莫非也是搞数学、物理的？

 

我在这个论坛上发现，“春光”、“浪淘沙”、“易子”等许多人逻辑分析能力不比我差，甚至要好一些，你们把我当权威，实在不敢当。

我真正比你们要权威一点的，看来也就运动学或物理学方面(我本来就是学物理的)，而万年历这个东西，我还得向大家多学习。

 

顺便说一下，千万不要用二分法求气朔，那速度低得要命。可以考虑使用牛顿求根法。如果觉得复杂，至少也要用截弦法，反正不要用二分法。