HP JavaScript 农历公历干支历互转,万年历,四柱,六十甲子,属相,十二星座,二十四节气 支持从-1000年至3000年间的八字排盘及大运推算,真太阳时排盘,分析刑冲合害关系 支持从-104年至2300年间的农历公历互转 -721年至2300年的公历农历与寿星万年历一致
算法原理为JS源码
此工具类包含:
1,儒略日历
以公元前4713年1月1日12时为起点,每天(每廿四小时)加一的历法;
比如2020年1月1日12点的儒略日为2458850,2020年1月1日0点的儒略日为(2458850 – 0.5)
这种历法方便各种计算,比如已知起点日为周一可求得任一日期的星期,已知起点日的干支可求得任一日期的干支
2,公历(阳历,格里历,西历)
以地球绕太阳公转计算的历法;
用公式可直接求得两分两至(春分秋分夏至冬至);
公转是椭圆轨道,把这个椭圆均分为24等分,可求得中国的二十四节气;12等分则为西方的十二星座;
此工具计算出的时间点误差在20秒内;
已知2020年春分点为3月20日11点49分57秒,则算法认为57秒前是双鱼座,57秒后是白羊座,是否按此计算请自行斟酌;
每月两节不变更,最多相差一两天.上半年来六廿一,下半年是八廿三 这里的六廿一和八廿三说的是公历;
3,阴阳历(农历,民间称阴历)
严格地说,以月球绕地一周为一个月计算的历法为阴历;
如果这样,阴历跟二十四节气的时间差就越来越大,我们可能要在夏季过大年初一;
也许人们为了能固定在立春前后吃上年夜饭(May be…),引入闰月的概念,使之与公转齐平,
所以农历考虑了月亮又考虑了太阳,为阴阳历;
陰曆正月與置閏这一段很难理解
4,干支历
这种历法现在可能多用于命理学和历史研究领域,与二十四节气相关;
由于一年只有12个月而不是60个月,一天只有12小时而不是60小时,所以合法的四柱并不是简单的排列组合;
年柱跟月柱有固定的关系:甲己之年丙作首,乙庚之歲戊為頭,丙辛歲首尋庚起,丁壬壬位順行流,若言戊癸何方發,甲寅之上好追求.
日柱跟时柱也有固定关系:甲己還加甲,乙庚丙作初,丙辛從戊起,丁壬庚子屬,戊癸何方發,壬子是真途;
所以不存在甲子年甲子月甲子日甲子时这么个时间.
八字组合共有518400种(不分早晚子时),且一個八字出現後,至少要60年後才会再出現,最多要240年後才又出現;
已知2020立春点为2月4日17时3分44秒,44秒前为己亥年,44秒后为庚子年;
已知2020驚蟄为3月5日10时57分22秒,22秒前为戊寅月,22秒后为己卯月;
是否按此计算请自行斟酌,尤其是要用在命理学上的时候;
5,真太阳时
粗略理解: 我们用的东八区时间(北京标准时间),是东经120度线的理论时间(平太阳时,平均太阳时)
按照地球自转一圈严格为24小时计算,正好每经度4分钟(24小时*60/360度 = 4分钟),我国跨越五个时区,已知经度和北京标准时间可以计算出地方理论时间(地方平太阳时,(J-120)*4).
实际上地球自转速度有快有慢,而且太阳并不总是从正东方升起,考虑这个快慢和倾角而计算出的时间为真太阳时,真太阳时的正午12点,正好当地的(如日晷)影子最短.
地方平太阳时与真太阳时有相对固定的差值,各地都一样,每年1月1日大约相差3分钟,12月1日大约相差11分钟,可以通过”真平太阳时差换算表”查得,本项目采用天文方法计算.
有说古人用日晷计时,没有北京时间的说法,所以排八字要用真太阳时,请自行斟酌
6,精确度问题
当前项目与寿星万年历(源码在 sxwnl 目录)进行过逐时比对[js/diff.js],结果如下:
公历儒略历部分完全匹配
节气及月相部分相差不超过20秒(均为天文科学上的算法)
真太阳时部分相差在20秒内,本项目考虑了纬度(均为天文科学上的算法)
PHP中的date_sun_info($timestamp, $W, $J)也能实现真太阳时的计算,与本项目的真太阳时模块有几分钟误差
农历-721年至2300年完全匹配(古代农历是完全从寿星万年历搬过来的)
四柱八字算法上,寿星不考虑年柱月柱的真太阳时,导致少量对不上
星座算法上,寿星精确到日,本项目精确到秒,导致节气交接日星座对不上
7,需要解释的
采取真太阳时排盘,由于年柱以立春为界,月柱以节令为界,那么廿四节气是否也要转为真太阳时?
真太阳时排盘有几种方案,请自行斟酌:
a.仅对日柱时柱做调整,年柱月柱不动(寿星万年历,常用方案)
b.年月日时柱均做调整,节气时刻不动(本项目方案)
c.年月日时柱均做调整,节气时刻均转为真太阳时(科学地说应该用此方案)
廿四节气是针对北半球而言的,南半球的干支历排盘以及星座等要如何处理呢?
