更新很快！

谢谢楼主的努力和辛苦。

V3.13版

根据“叶风杨”兄的农历节日数据，增加了一些农历节日

 

写“万年历”的工作量很大，有点超出我当时的想象。刚开始写的时候，本以为只需一两个星期就可以解决问题，想不到搞了几个月还未能发布完整版。

许兄辛苦了.

你开始是单兵作战,进度可能会慢些的.

不过,只要你发布出来,我们大家一块使用.至少可以帮你查漏,查错.这样相对就好多了.也越来越完整了.

希望能继续.

还有那个日月食,似乎对你也不难的.既然你的软件已经可以计算太阳,月亮的方位角及高度角,我想已经接近推算日月食了.理论上,只要观测者看到太阳与月亮的方位角与高度角接近时,应当会发生日食的.

问题如下：

1、星历(九行星及恒星)计算方面的C++算法在今年4月份已全部写好，但一直不敢把它转换为JavaScript程序。关键问题是javascript的运行速度问题。如果加入了五行计算，造成软件变慢太多，就没有太大意义。五行计算所需的作标变换比日月计算的变换要多一些，速度比日月计算要慢一些，是否可以考虑降低精度，比如降低到“角分”精度，不知这样大家会不会接受。

再者，九行计算的数据量很大，程序可能又要上涨近百k，也是很头疼的事。

2、日月食的计算是很麻烦的，如果仅仅是计算有无日月食（如《天文算法》或“日梭万年历”中所介绍的），那单然比较简单。但这样计算意义太小。举例说，我们都知道今年8月有日食。关键问题是在哪里有日食，路径如何，在全球范围内的情况是怎样的，在北京会是怎样的情形，在福建又是怎样的？要算出这些，需要直观的图形处理才有价值。我一直认为，计算日月食的“有无”是没有意义，如果这样，不如拿出近几千年的日月食总表即可，不必现场计算，现场计算无疑会降低程序性能。我的思路是，利用vml图形处理方法计算全球的日食情况，我有信心把这个做成《日月食宝典》。

3、在日食计算中，地球不是正球形，无形中给计算带来不少麻烦。我再考虑使用根数表计算日月食，效果可能会好一些。还有一种思路：把日食参数先用C++算好，在Javascript中调用这些参数，可大大减少计算量。

4、总之，在功能与性能方面还有很多需要平衡考虑的因素。前一段时间我有考虑过这些问题，但后来搁置，而先把万年历做好，然后再考虑天象问题。

不知大家有何想法，不妨一同讨论。

这些计算可以单独列出，只在主界面上作个链接。

真要是比较复杂的话可以先不考虑。

我觉得作为一个万年历，目前的版本已经很完善了，不需要太复杂的功能。要预报五行或九行的具体天象应该另做一个软件比较合适。目前有一个很优秀的开源观天软件可以做到这点--Stellarium，或许许兄单枪匹马做这个观天软件的工作还不如加入到Stellarium的开发团队中去更有效果。http://www.stellarium.org/wiki/index.php/%E9%A6%96%E9%A1%B5

万年历加入一些小功能，如预报有无日月食，这样很好，但是如果太详细，则完全没有必要，那样的话，万年历就不是万年历了，而是观天软件了，年历的作用反而成了附属。

Stellarium 这个软件有近40M之大

其实观星软件不少，象 “看星空” 0.8就不错

但是能预报日食的软件确实不多

已发布v3.14

1、根据叶风杨的建议(在他的html版)，把鼠标经过的显示框位置作了调整。防止显示框超出日历区。

2、修正时区信息的“中南”、“大洋”的错误，改正为“中南美洲”“大洋洲”

3、再次改写内核结构（不改算法）

内核基本组成为：

(1)XL 物件：星历物件

(2)obb物件：农历通用的常数表、天文算法计算气朔函数等、公历农历的节日判断函数等

(3)SSQ物件：农历的气朔计算表计算器(含古历算法及天文算法)、年历排定(定出月序、闰月、月大小、月建)等

(4)Lunar类：这是一个类，不是物件实例。功能：产生月历详细表。

调用方法示例1：

var lun = new Lunar(); //生成月历物件

lun.yueLiCalc(); //生成月历

调用后，lun物件将产生很多农历信息

调用方法示例2：

var lun = new Lunar();

lun.yueLiHTML(); //生成月历HTML

yueLiHTML成员函数与页面生成有关。如果对版面不满意，改这个函数的内容。

说明：

1、程序结构基本上比较合理、标准，有空的时候写一个编程技术档案，这样就可在《寿星万年历》的基础上进行二次开发了。

2、注意程序中的public申明与private申明，javascript不易做到公有或私有申明，所以的物件或类，其成员都是公有的。如果我在注释中申明为私有，用户不要调用（它是成员函数内部自己调用的，与用户关系不大）。很多函数是私有函数，抛开么有成员函数再去理解程序结构，就会发现程序没几行。

我也在考虑使用单独列出，不在主界面，这样就不会影响性能。看来已后还是往这条路子走比较正确。

  我刚才分析了一下，我觉得日食问题在《寿星万年历》中实际上已经基本解决，只是没有利用图形表示出来。因为日月在站点坐标(观测者位置为中心的坐标)中的视位置及视大小在寿星万年历中已经全部精确的算出，这时候只需把日月位置表达为图形，就日食情况非常明确，即在什么时刻发生日食，食的情况就一目了然。《寿星万年历》左边显示的那些坐标简直就是为“日食情况”准备的，那段程序没有白写。当然这种方法只能知道在观测者所在地日食情况，不能得到日食的全路径。

  不过寿星万年历中还没有给出月食的算法，有空的时候得再加一个函数算月食。

  五行计算还是有点麻烦。看来还是得独立一个页面来解决问题。