cnlunar
cnlunar copied to clipboard
OPN48
报告一个不匹配的日期与八字
输入阳历：1991年4月5日3时 输出八字：辛未 壬辰 乙巳 戊寅
但与多个八字排盘软件显示，应该是：辛未 辛卯 乙巳 戊寅 月柱好像错了，不应该是”壬辰“，应该是"辛卯"
请有空查下孰对孰错，谢谢！
输入阳历：1991年4月5日3时 输出八字：辛未 壬辰 乙巳 戊寅
但与多个八字排盘软件显示，应该是：辛未 辛卯 乙巳 戊寅 月柱好像错了，不应该是”壬辰“，应该是"辛卯"
请有空查下孰对孰错，谢谢！
多个软件说的是什么软件？
输入阳历：1991年4月5日3时 输出八字：辛未 壬辰 乙巳 戊寅
但与多个八字排盘软件显示，应该是：辛未 辛卯 乙巳 戊寅 月柱好像错了，不应该是”壬辰“，应该是"辛卯"
请有空查下孰对孰错，谢谢！
大概原因说一下，月柱的变迁不随农历月份变迁，而随二十四节气，1991年4月5日属清明节，但3时应该未到精准的轨道分秒，第一种可能是他们错了，第二种可能是他们使用记录不一样的数据源（比如写邮件给紫金山天文台，让其提供自1966年独立计算出中国天文年历以来，每年的历书数据。联系方式：[email protected]），导致因为时辰未到清明准确时间，所以3时还不算清明节，不变更月柱。本算法原始数据来自于香港紫金山天文台，并没有提供过去和未来精准的时分秒数据，https://www.hko.gov.hk/sc/gts/time/conversion.htm
输入阳历：1991年4月5日3时 输出八字：辛未 壬辰 乙巳 戊寅
但与多个八字排盘软件显示，应该是：辛未 辛卯 乙巳 戊寅 月柱好像错了，不应该是”壬辰“，应该是"辛卯"
请有空查下孰对孰错，谢谢！
所以本算法认为，当日为清明节，月柱应当变更，由于星体间存在慑动，观测也存在误差，我们也无法确定每个人出生的秒是否为标准授时秒，而八字在规划年柱月柱月柱时柱时，最小精度为2小时，基于现有的数据和科学基础，我们确实没办法真正精准地获前后一百年间的数据，香港天文台也在数据源底部标注： *由于计算数十年后的月相及节气时间可能会有数分钟的误差，若新月(即农历初一)或节气时间很接近午夜零时，「对照表」内相关农历月份或节气的日期可能会有一日之差别。这些情况会出现在2057年9月28日、2089年9月4日及2097年8月7日的新月、2021年的冬至、2051年的春分、2083年的立春和2084年的春分。
- https://6tail.cn/calendar/api.html#demo.bazi.html，
- http://zydx.top/
- http://www.paipan.wang/?s=8217&_is=1&_iw=1280&_ih=1296
以上三个，都是 输入 1991年4月5日3时，可得 辛未 辛卯 乙巳 戊寅。其中第一个为日期计算，后两个为排盘工具
谢谢您上面的解释，若遇到类似情况，还是不知道应该如果处理，应该采用哪种算法
- https://6tail.cn/calendar/api.html#demo.bazi.html，
- http://zydx.top/
- http://www.paipan.wang/?s=8217&_is=1&_iw=1280&_ih=1296
以上三个，都是 输入 1991年4月5日3时，可得 辛未 辛卯 乙巳 戊寅。其中第一个为日期计算，后两个为排盘工具
谢谢您上面的解释，若遇到类似情况，还是不知道应该如果处理，应该采用哪种算法
@6tail https://github.com/6tail/lunar-python 在农历运算的开源项目中也是十分优秀的，我来解释一下我们两个方案的不同： 首先， @6tail 在项目之初就为了农历的年份跨越度，直接使用了儒略历方案，我在写的时候也有考虑用儒略历，在写到二十四节气部分时，由于地月围绕太阳本身就属于椭圆轨道，地球围绕太阳速度不一不说，从天文学角度出发，实际上也会受到木星等大天体的影响产生微量的慑动，我本身就是为了毕业论文撰写项目，所以我的版本更多的会参考国家授时标准和《钦定协纪辨方书》的约束，这里开始我就使用了压缩数据表法，仅用了香港天文台1900-2100的数据，而6tail的可以从公元元年至-公元9999年推算，他项目代码中儒略历转化如下：
def fromJulianDay(julian_day):
d = int(julian_day + 0.5)
f = julian_day + 0.5 - d
if d >= 2299161:
c = int((d - 1867216.25) / 36524.25)
d += 1 + c - int(c / 4)
d += 1524
year = int((d - 122.1) / 365.25)
d -= int(365.25 * year)
month = int(d / 30.601)
d -= int(30.601 * month)
day = d
if month > 13:
month -= 13
year -= 4715
else:
month -= 1
year -= 4716
f *= 24
hour = int(f)
f -= hour
f *= 60
minute = int(f)
f -= minute
f *= 60
second = int(round(f))
if second > 59:
second -= 60
minute += 1
if minute > 59:
minute -= 60
hour += 1
return Solar(year, month, day, hour, minute, second)
其次，两个项目的编写思路不一，cnlunar编写思路主要还是在于设计一个文言文转算法的模型，让宜忌神煞更为还原典籍（从《钦定协纪辩方书》中列出），所以你可以看到项目内大量的代码都是在算每日值神并推每日宜忌的，这块也是github上比较缺少的，很多项目都是通过寿星通式拟合算随便推，而@6tail 编写代码更为规整，从内部你可以看到他写了很多test的方法一直在矫正农历、八字、节日等，在每日宜忌部分，@6tail 也在项目内说明了：
https://6tail.cn/calendar/api.html#lunar.yiji.html
每日宜忌指当天适合做什么，不适合做什么。
关于每日宜忌，网上资料甚少，也没什么有价值的代码可以抄袭（可能会有人要抄我代码了，呵呵），后来我想宜忌数据肯定也是有轮回的，并且跟年份关系应该不大，最终从某网站(http://tools.2345.com/rili.htm)爬取了10多年的宜忌数据拿来研究，并发现了一些规律，制作了一个宜忌数据表，通过查表获得每日宜忌。
综上，如果你对年份跨度算法更偏向于儒略历为基准，以推算方式确定二十四节气，则@6tail 的项目比本项目更加优秀。如果你的用途是以”日家“为基础，并且数据源有明确考证及符合科学（当然这是我毕业论文对精准度的需要），又对每日值神神煞文化依据有额外需求，本项目更适合。虽然我的python版本项目star比@6tail 的python版本多一些，但我个人认为，@6tail 提供的项目有javascript java csharp php python go不同语言版本，在兼容范围广度上比本项目更广，从项目代码质量上应比本项目更为优秀。
3时未到精准的轨道分秒，八字应该是辛卯，过了精确时间后才是壬辰，大概率是你算错了。
https://github.com/OPN48/cnlunar/issues/18 这里回答过了《钦定协纪辨方书》本就未到秒级别，香港天文台也未提供两百年精准秒数据，另外太岁星也是虚拟星，论文讲究真实可溯源，仅符合日家算法，和西历2月润一天一样，历法属于约定统一，不支持算命伪科学
3时未到精准的轨道分秒，八字应该是辛卯，过了精确时间后才是壬辰，大概率是你算错了。
你要是能给我可信的200年数据源，我可以压缩后算，这个没啥算法上的难度，一般天文台只会发布最近一年的
应该是：乙丑乙酉庚辰辛巳 实际是：乙丑丙戌庚辰辛巳 时间是：1985 1008 1030 这个月柱子也是错的,实际9.15到10.13都是乙酉月 @cuba3
您的依据是？
应该是：乙丑乙酉庚辰辛巳 实际是：乙丑丙戌庚辰辛巳 时间是：1985 1008 1030 这个月柱子也是错的,实际9.15到10.13都是乙酉月 @cuba3
您一直给我这边报各种神奇错误，能不能给一个你查询的依据？百度1985年10月8日 老黄历1985年10月8日