這邊比較好奇的是
天文演算的部分
這邊主要按照
Jean Meeus, Astronomical Algorithms, 2nd Edition. 《天文算法》2版
操作

天文演算採用完整的 VSOP87 (VSOP87D.ear) 來計算行星的日心座標位置，以 LEA-406 來計算月亮位置。LEA-406 基於 LE406，據 Sergey M. Kudryavtsev，較 ELP/MPP02 更貼近 LE406。
但是算出的數據大都會差到幾分鐘

猜測可能是大氣折射
或者是多個演算來源配合方面出了問題

但是當然不好意思麻煩您幫我檢查...
https://github.com/kanasimi/CeJS/blob/master/application/astronomy.js

想要請問一下
不曉得現在有沒有比VSOP87更方便單機使用的數據

另外若是這邊想要進行整套的天文演算
不曉得您有沒有什麼可以參考的資料?

謝謝您

用TDBtimes_extended.txt的数据写了一个自己用的历法纪年软件
在不计算润秒的前提下节气时刻和寿星天文历法对比相差基本就是没有计算润秒的数值
到2600年(虽然今生用不到这数据)的时候节气时间和寿星天文历法差了将近半个小时 随着时间的推移 这个差值会越来越大
这是因为没有计算润秒还是因为数据本身就是这样的呢 ？方便修正吗?谢谢

Hi，ytliu0，你好。

我在算日期的时候有一点疑惑。特像你请教。

根据《后汉书》记载，中平六年十二月戊戌，“詔除光熹、昭寧、永漢三號，還復中平六年。” （reference https://ctext.org/hou-han-shu/xiao-xian-di-ji ）

https://ytliu0.github.io/ChineseCalendar/era_names_simp.html 而此处汉献帝，中平六年对应的时间是公元 189 年。

但是用 https://ytliu0.github.io/ChineseCalendar/ 计算出来的中平六年十二月戊戌，似乎只有闰十二月的日子里有戊戌，这时候也已经是公元 190 年 2 月 19 日。（距离下一年正月初一也只差四日）

如果记载没问题的话，也许应该认为中平六年是在新年前几天被重新恢复的？

从 公 历 和 农 历 日 期 对 照 这里搜23年，可以看到23年的农历年月的顺序是 正月、二月、三月、...、十月、十一月、十二月、十二月。正月之后是二月，并且有两个十二月。

关于这年的月份，有两个疑问：

1.有地方的资料说这一年应该有两个十月，而不是两个十二月，例如 网页1，网页2，

5)公元23年，淮阳王改元更始，复用寅正，以地皇十一月为更始1年的十月，故该年有两个十月。

1、**研究院公元23年是两个十月，寿星万年历中是两个十二月。

应该哪个是正确的呢，或者说这个目前还存在争议？

2.看资治通鉴里更始元年部分的记载（Wikipedia）， 里面某几个月份的朔日跟日历里对不上，但是有个奇怪的地方就是，日历里某个月份的下一月的朔日，刚好都能跟资治通鉴里的对上。例如资治通鉴里记载更始元年：

二月，辛巳朔

六月，己卯朔

九月，戊申朔

但日历里却是：三月，辛巳朔；七月，己卯朔；十月，戊申朔。如果史料对的话，反过来推断，更始元年的正月之后，有没有可能是一月，而不是二月？建寅月要么是正月、要么是一月？

感谢提供的TDB数据。根据数据自己写了一个计算程序。发现2033置润确实和您博客里面提到的一样。是错误的我现在程序显示2033润月月份在农历7月。请问您置润的方法是根据月份内不含中气吗？如果不是的话这个置润该怎么计算呢？谢谢。

Amazing resources, thank you!

There is a visual bug that is happening all over the site with regard to pinyin:


Looks like Verdana doesn't show the 3rd tone properly. Perhaps having Arial as the main font could solve the problem. (Or even adding Noto Sans and combining it then with Noto CJK for most optimal typography)

On another note, I'm surprised you are using 1 + mod(y+6, 10) for stem and 1 + mod(y+8, 12) for branch. Is there a particular reason for this? Why not use this method: https://zh.wikipedia.org/wiki/%E5%B9%B2%E6%94%AF#%E8%A5%BF%E6%9B%86%E2%86%92%E5%B9%B2%E6%94%AF%E7%B4%80%E5%B9%B4

Also, <a href="Era_names.html"> should be changed to <a href="era_names.html"> in others.html. Otherwise the link is dead.

很棒的工作！

对我国古代历法很感兴趣，这里是我找到的介绍最全面、丰富、精确的地方，可惜的是没有介绍到古代历法中关于行星的内容，略微有些遗憾。

能否在主页介绍相关内容？

或者，提供现代高精度五星运行相关数据来源，以供爱好者推算。

又或者，给个能查到相关数据的网址也行。

谢谢大佬。

作者您好，首先感謝您提供的公曆和農曆日期對照 Project，我也是個古曆法研究愛好者，但是非專業人士，有個問題一致困擾我，倘若作者瞭解，還希望不吝賜教。

問題是這樣的，我們都知道根據天文算法計算日曆會有一定程度的誤差，以計算二十四節氣為例，其精度可以精確到毫秒，打個比方說某年的“大雪”發生的準確時間為 12-07 的 23:59:59.47，如果計算精度的誤差為一秒，那麽該年大雪就有可能是 12-08 號而非 12-07 號。同樣的問題也會存在於合朔的確定上，如果合朔發生的時間距離兩個日期交接的時間非常近（23:59:59 或 00:00:01），那麽合朔具體的日期就變得難以確定，進而農曆月的起始就會出現誤差。

因此我想問一下作者是如何確定這一時間的呢？曆法規則上對此類特殊情況有沒有什麼特別的說明？謝謝！

我在查閱作者提供的文檔時，發現在式(41)下您有提供地心視黃經的公式 λ = arg(Xec +iYec)，但是並沒有在文檔中找到實數 Yec 的定義，想問下您 Yec 的具體含義是什麽？謝謝。

偶然间发现813年3月的日历里，月相里朔是 6d19h54m ，按理说初一应该是3月6日，但实际初一是 3月7日，出现这个情况是为什么那？

Hi @ytliu0 非常感谢您的工作！

我在确认一个天文现象，后汉书中光武帝纪第一下记载光武帝七年三月癸亥日发生了日有食之，日月薄食

在您公历和农历日期对照中我发现这个日子对应的是

格里高利历31年4月30日，农历三月二十。

但是农历三月二十月由盈转亏，看样子不可能发生日有食之吧。

请问您知道后汉书这里所采用的是什么历法吗？可以直接对应到您创建的那个网页上的日历吗？感谢您的回答！

Email from someone:

On the conversion page, I found I could not do a conversion for the Julian years 13, 16, 19 and -103. When I enter any of those years, the webpage simply doesn't respond.

现在**各地采用的时间是东八区的区时，比UTC迟八小时，一般以UTC+8表示，也称为北京时间或**标准时。

这里面的 比UTC迟八小时 应该是 比UTC早八小时 吧？

出现的位置:

在參閱作者的農曆編算方法檔案時，看到您在使用牛頓-拉弗森對節氣和月相求根的時候先根據指定的時刻 t0 推算出 t1。

這裏晚輩有一個疑問，對於月相的� t0，可以隨機指定某一天開始往前或後進行推算；但是對於節氣，是否可以直接將 t0 限制與區間內呢？晚輩的想法是鑑於節氣的發生日期大多是在每月的 5 日左右和 20 日左右，在進行推算時將節令的 t0 限制在 5 日而中氣限制在 20 日開始迭代是否可以更快地收斂？

晚輩嘗試過選取 t0 在 5 日以及選取 t0 在 20 日時推算 節令，但是收斂速度貌似沒有多大變化。

感谢作者提供的资料　我是一个业余编程爱好者　因为编写民间择吉部分需要用到历法计算
所以看到了这里提供的资料和方法　按照您博客里记载的方法：农历编算方法和农历编算例子　计算从M-1到M11之间的朔的数目LY　是根据儒略数来算的吗？我始终计算不到润年　而且这个数值如果根据TDBtimes.txt文件来计算的话　应该怎么算呢？谢谢

回應kanasimi的問題：

**不曉得這邊的古六曆，是否有可能匯出成

1.第一欄是當年的歲首JDN
2.第二欄是所有當年月份的日數

這樣的形式呢？例如 春秋曆:

1457728 29;30;29;30;29;30;30;29;30;29;30;29**

下面的 JavaScript 程式應該可以滿足你的要求。這是按照這裡古六曆網頁的方法寫的，置閏法則採用固定冬至法。

// 古六曆參數
function guliuli_calendar_parameters(li) {
    var jdM0, JDw, jian=0;
    switch(li) {
        case "Zhou":
            // 周曆
            jdM0 = 1683430.5001; 
            JDw = 1721050.5001 + 0.75;
            break;
        case "Huangdi":
            // 黃帝曆
            jdM0 = 1783510.5001; 
            JDw = 1721052.5001 + 0.25;
            break;
        case "Yin":
            // 殷曆
            jian = 1; // 建丑
            jdM0 = 1704250.5001;
            JDw = 1721051.5001 + 0.5;
            break;
        case "Lu":
            // 魯曆
            jdM0 = 1545728.5001 + 419.0/940
            JDw = 1721050.5001;
            break;
        case "Zhuanxu":
            // 顓頊曆
            jian = -1; // 建亥
            jdM0 = 1726575.5001;
            JDw = 1721050.5001 + 19.0/32;
            break;
        case "Xia1":
            // 夏曆(冬至版)
            jian = 2; // 建寅
            jdM0 = 1883590.5001;
            JDw = 1721053.5001 + 0.75;
            break;
        case "Xia2":
            // 夏曆(雨水版)
            jian = 2; // 建寅
            jdM0 = 1883650.5001;
            JDw = 1721052.5001 + 0.875;
            break;
        default:
            console.log("這裡沒有 "+li+" 的曆法數據.");
     }
     return {jian:jian, jdM0:jdM0, JDw:JDw};
}

// 古六曆計算函數
function guliuli(li, y) {
    // 朔策和歲實
    var lunar = 29 + 499.0/940, solar = 365.25;
    // 讀取曆法參數
    var p = guliuli_calendar_parameters(li);
    // 天正冬至的儒略日數
    var Z11 = p.JDw + y*solar;
    // 建子月朔(天正經朔)
    var i = Math.floor((Math.floor(Z11 + 0.5) + 0.5 - p.jdM0)/lunar);
    var Mzi = p.jdM0 + i*lunar;
    // 此歲有閏月?
    var leap = (Mzi + 13*lunar > Math.floor(Z11+solar+0.5)+0.5 ? 0:1);
    // 年首月建的朔 (顓頊曆:十月, 其他曆法:正月)
    var M1 = Mzi + p.jian*lunar;

    // 年首月建為建丑或建寅的曆法
    if (p.jian > 0) {
        // 閏月使正月推遲一個月
        M1 += leap*lunar;
        // 下一歲建子月及冬至
        Mzi += (12+leap)*lunar;
        Z11 += solar;
        // 下一歲歲有閏月?
        leap = (Mzi + 13*lunar > Math.floor(Z11+solar+0.5)+0.5 ? 0:1);
    }

    var Mi = M1 + 0.5;
    var cm = [Math.floor(Mi), 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0];
    for (i=1; i<13+leap; i++) {
        cm[i] = Math.floor(Mi + lunar) - Math.floor(Mi);
        Mi += lunar;
    }
    return cm;
}

用法:
執行 guliuli(曆法, 公曆年份) 就會輸出一個Array，含有[歲首JDN, 日數, 日數, ..., 日數]，如果Array的長度是13，則該年沒有閏月，如果Array的長度是14，最後一個數字是閏月的日數(閏月總是置於年終)。

例:
console.log(guliuli("Zhou", -386));
輸出:
[ 1580043, 30, 29, 30, 29, 30, 29, 30, 29, 30, 29, 30, 29, 30 ]
就是古六曆網頁例一的結果。

console.log(guliuli("Xia1", -386));
輸出:
[ 1580131, 30, 30, 29, 30, 29, 30, 29, 30, 29, 30, 29, 30 ]
就是古六曆網頁例二的結果。

如果要把數據分成你說的兩欄也不難，例如：
for (var y=-479; y <= -221; y++) {
var cm = guliuli("Zhou", y);
console.log(cm.shift(), cm.join(';'));
}
這就印出了從-479年到-221年的周曆數據。

我檢查了幾個年份和幾部古六曆都沒有錯，但是還是建議您再檢查一下以防有bug，如果發現有 bug 請告知。

最後要說的是春秋曆不是古六曆，不能用古六曆的方法計算，因為其置閏沒有常規，需要另外用Array儲存有閏月的年份。

感謝您釋出這個工具
您提到

歲差採用Vondrák等人於2011年建立的歲差模型Vondrák計算。

網路上面另外可以找到唐凯的
A long time span relativistic precession model of the Earth
請問兩者間的精確度以何者較佳呢

感谢作者分享的资料 没写过历法 跑了一个差不多两百年的时间发现,
阳历时间2052年12月21日,农历时间2052年十一月初一,这一天正好是冬至也是农历月份初一.
自己写的程序数据显示2053年距离冬至前最近的一个朔日期是阳历时间2052年12月21日.正好和冬至这一天重叠了.
这样的现象是我计算错误了吗?
如果不是,请问这个日期可以作为距离冬至日最近的一个朔的日期来计算吗?
谢谢.