看来问题还是有一些啊.

不但公元前有这个现象,公元后也照样有这个现象的.

比如2000年第一个节气冬至,最后一个节气小雪.(大雪就没显示了.实际大雪应当显示在十一月份,冬至节气前面才好.)

比如公元2519年,第一个节气冬至,最后一个节气是立冬,后面的小雪,大雪都没有显示.

我估计问题出在许兄把冬至排在一年的第一个节气造成的.这样,若十一月份有大雪节气(当然在冬至前面),这一年的年历计算结果就显示不出来大雪了.

已发布V3.33版

根所浪淘沙指正：

1、修正了年历中没有输出“大雪”、“小雪”的问题

2、修正年历中上下换年按钮显示标签符号。

“地方食表”中我随便输入了几个地标数据，这些数据来自《2008年中国天文年历》；海拔高度数据从网络上找到，我无法考证数据的准确性，我想可能是平均高度吧；不过，对于日食计算来说，几十米的高度误差对计算结果的影响不大（小于0.2秒）。《寿星万年历》允许一次性计算几百个地方的日食数据，可以考虑扩充一些。

地标数据确实没有统一的.把杭州的坐标中心定在“紫薇园坐标原点”比较合适。查GoogleEarth,坐标为30°14‘44“N，120°09’37”E，四舍五入，正好是许兄第一次给的数据（经度-120°10‘，纬度30°15’）。海拔高程60英尺（18米左右）。

建议许兄在软件的界面设计一个地理坐标“导入”“导出”按钮，这样，在许兄更新版本时，我们自己就可以把坐标数据导入进去。

另提一个小建议，计算日食时，似乎可以再计算一个参数：“最大食分”。这样，各地在看日食时，就可以大概了解一下本地的偏食到底有多大？

3.33版把上年的气归于当年是不合适的，建议年历以冬至始、大雪止。可参考我的修改版。

气的归属似乎也是一个矛盾.

如果从冬至始,到大雪止.那么如果冬至不是十一月的第一个气,就得把第一个气(往往是大雪)当作上一年的.也就是把一个月里二个气分别归到不同的年份了,似乎也不太好.

看来得折衷考虑了.

我的观点：

《寿星万年历》中的年历输出方式不是很规范，正是一种折衷的显示方法。

我们知道，农历是一种阳阴合历，实际应用以月历及两三个重要节气为主，其它节气为辅助。总体上说，以月历为主，这样，规范的排历最好从正月开始输出年历。形式如下：

正月 含 某某气

二月 含 某某气

……

但这种输出方式有几个麻烦的事情：(1)一年中的月历包含在两个阳历(节气)年之中，这也是现行农历的不足之处。对于古人，最容易测定的节气就是冬至，与今人相距太大，如果今人，多半会考虑使用春风(西方喜欢用的)或立春（曾一平喜欢用的）为阳历的年首，即把包含春风或立春节气的月份固定为正月。如果是这样，就不会出一个阴历年跨越两个阳历年的问题，造成年历输出困难。也就是说，从正月开始输出一年的现代农历的年历，必需计算两年的农历才可能实现。(2)古人常改月建。

如果按叶风杨的想法输出年历，最好格式如下：

冬至 节气2 含 某某月初一

节气3 节气4 含 某某月初一

节气5 节气6 含 某某月初一

……

但由于农历以月历为主，所以这种方式输出也不合理。

《寿星万年历》使用了综合以上两种方法，做了折衷：

以天正月(十一)开始输出，即按阳历方式输出，但输出表的主索引列却是月亮历。这样可避免一次性计算两年的农历。使程序效率提高一倍。如果程序调用相同的函数十次，仅计算10或11年的农历，即可得到10年农历。当把这10年的农历串起来，这10年的农历就是完整的。

利用《寿星万年历》的这种输出方式，把连续两年的年历串起来，再去除第一个正月之前及第二个正月之后的月份，就得到完整一年的日历，也就是说，规则范的年历输出可以在《寿星万年历》现有函数基础上扩展得到，那么这个现有函数正是我们所需的“基础的标准函数”

呵呵~~~许老师辛苦了~~~祝愿您新年好运连连！！！

嗯，每个人的习惯风格不同，我还是喜欢月历以月为主体、日为元素；年历以年为主体、月为元素的风格。也就是说优先考虑主体的完整性，再考虑元素的整体性，而超出范围的元素不考虑。如考虑气的日归属只要看气的时刻归属哪日即可，而不考虑月归属或年归属；考虑气的月归属只要看气的时刻归属哪月即可，而不考虑日归属或年归属。

现在年历中不考虑年（24气）的完整性，却去考虑日的完整性，我不喜欢这种风格。