还是有小错误的.

比如在算日食时,如果你输入的时间是17:00(没有秒数),点确定,就出错了.

还有在坐标计算时,如果输入的年份是公元前,比如B200,点确定也会出错的.

(算日食时,可以输入公元前的.B200不会出错的.)

寿星万年历3.26.1单文件htm版：

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

点击浏览该文件:

基于3.26版修改。
加入地图，更新地图中城市的坐标，改进版面......

风扬兄高人啊！上周的星期天，我画了一天地图(主要搞那个坐标)，也没画好，不知您是如何画的。

哪里哪里，其实几年前我把林洵贤的200年日历兼容到Linux平台的时候就弄过这个。长时间没弄java脚本，很生疏了，昨天仔细调了一晚上，几乎是一个个参数试过功能后再用二分法改像素值这个很笨的办法才调出这样的效果，真是贻笑大方啊

这个其实很简单，就是用div定位。地图用的是webdings字体，虽然比较粗糙，但大致还是不差。

上次你说画图没办法兼容Firefox，其实我觉得可以用多层div叠加来实现的。

另外提个建议，加个开关，使日月可以地理坐标运行。

其实日历到这个程度，日食带也很容易画出了。就是本影区（全食或环食看距离）和半影区（偏食）扫过的面积嘛

月食带也类似。

用“层”确实也可以实现，主要修改ht_b与ht两个作图类就可以了，不过改写这两个类要花不少时间。个别无当兼容的，可以考虑更改函数的接口（主要是ht物件中的shape()方法）。

我当时是想把它做成正投影球面立体坐标的，并且这个坐标可以根据用户需要自己旋转，这时使用“层”将变得很困难。程序写着写着，发现还需要很多与坐标旋转控制的程序要写，很麻烦，后来干脆使用平面直角坐标。早知道是这一个结果，当时我就不会选择VML。

顺便问一下，经您的调试，与fireFox主要存在哪方面的不兼容，主要是什么原因？

我对编程是菜鸟，纯粹属于有空时候吓琢磨，理解的并不深入，做做表面工作还马马虎虎。所以我对于不兼容firefox的地方也就知道一些比较浅显的，如event问题、滤镜问题、字符编码问题...这些比较容易解决，我就会改。

现在寿星万年历对firefox不兼容的地方我从表面看是几个下拉框的信息读不出来，还有就是VML了。其他的计算模块我试过，都很好。

寿星万年历3.32.1 单文件htm版：

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

点击浏览该文件:

基于3.32版修改。

增加月食种类预报；
增加日期计算工具；
修正年历可能不显示大雪的问题；
修改图表版面、配色；
默认使用地理坐标显示天体位置；
使用站心坐标显示天体方位时视向选项才有效；
站心坐标以正北为0，横坐标随视向改变；
修改计算工具中定气计算早一年的问题；
修正“太源”为“太原”，“乌鲁”为“乌市”；
其他同上一单文件htm发布版。

不过年历中还有一个小问题：
如1980年 冬月大 12-07(07 22:35:02) 大雪12-07(07 07:01:16)
12月7日有大雪和朔，但是大雪在朔之前，应该归十月。

如果节气时刻在朔之前都要归上个月的话,那么应当改历了.(前段时间有朋友论过所谓"历理置闰",就是讲这个问题的.)

现在除了八字四柱计算完全按节气时刻来排日子的,其它的大概都是按日过下中天时刻(0:00?平太阳时?)为一天的起始吧.所以我觉得在普通的民用时,还是按节气及朔所在日来定日期吧.不必分气在朔先还是气在朔后.

其实算命用的历书,其精度往往很低.我有一本万年历(上面也印了所谓的四柱),上面印的节气时刻在上个世纪八十年代时还算准的,到九十年代时,就差得老远了.若按那本历书来算命,估计会算错时辰的,那么命运就完全不一样了.