繼去年上半年，做好紀年轉換工具的基底程序後，一直對之前沒有能完成的，尤其是太初曆日的部分感到遺憾。每每看到那空著的一塊，就覺得有些缺陷。
最近又看了些東西，包括複習以及補強了一些之前出版但沒深入閱覽的書籍與論文。首先是太初历特殊置闰问题以出土漢簡說明過去常用的太初曆譜與實曆有出入，我查了一下意外發現我使用的正是其中所言，與漢簡記載不同的閏朔。另外，中國史曆表朔閏訂正舉隅，以當時墓碑碑文的紀錄與當前使用的閏朔表有差，證明就算是過去廣泛被利用、流傳的曆日，都有可能不正確。這讓我有些激動：原來過去我們認為沒有問題的曆數資料，都可以因為一些古代資料的發現而被推翻。更讓我驚駭的是，我知道很多人其實寧可相信漢書記載的是錯的，自己由曆法算出的才正確。但很顯然事情不見得像我們想像的那樣。
其實在做完轉換工具時，我就有種自負：雖不能說盡善盡美，但這已是東亞各王朝紀年與公曆間，現在資料最新（不說正確）、使用上最方便的轉換工具。因此既然發現資料有誤，當即更改。除了中國史曆表朔閏訂正舉隅提到麟德曆裡面附上朔閏表外，還發現春秋时期鲁国历法研究一書裡面包含了春秋時期魯國曆數。在發現可能納入此書資料後，就在考慮到底要不要作。由於其中只包含了春秋時期，因此就算作完，勢必也會留下兩個洞：戰國時期以及太初曆頒用期間。但我就想到了，說實在春秋时期鲁国历法研究資料也不見得完全準確啊，頂多只能說是「與當前所有證據相符」。那我所要採用的，到底應該是甚麼樣的標準？
之前就提過，每個月有幾日，以至記年的結構（有沒有年月日這些概念）都因文化而不同。何況就算能「算」得出來，也不保證不會因為意外（如改變算法、沒能及時拿到最新曆數的情況）而出現異常。舉例來說，中國史曆表朔閏訂正舉隅提到，中國古代皇帝避諱正旦日食，可能會多閏個一月來避免。這說明皇帝是有能力，也確實會因為非科學因素，而改變曆數的。而皇帝的思考或是這些非科學因素，不是由簡單的算法可以得出。春秋时期鲁国历法研究也認為，光是以算法推論不精準，應該是算法加上史實（例如史書、簡牘與碑文記載）比較恰當。既然重點要放在對歷史上實際施行、使用過的曆數作正確紀錄與轉換，我打從頭就不準備要用算的，而採取了查表法。
也就是說，這些曆數其實沒有我們想像的那麼嚴謹。假如一直拘泥於準確，卻會失了實用性。因此，最好的方法說不定就是讓此工具的資料維持在最新無矛盾的狀態，等有更新資料出來時再更改吧。以此標準來說，我該做的應該是把其他沒輸入的期間，採用寿星天文历資料，並加上「精確度前後 2個月」的註記。至於後面這些有更進一步資料的部分，則詳實附上資料來源。只要使用者——無論是文史工作者或是一般大眾——在嘗詢時沒有矛盾，也就夠了。這樣一來，應該會更好用。
紀年轉換工具:
https://kanasimi.github.io/CeJS/_test%20suite/era.htm原始日期
需注意的是，不可加工。例如原文作「三月甲申」，就不應該自行轉換成「三月三日」之類的，甚至直接就記成公元日期。畢竟如前述，只要有個新物證出土，難保過去以為的不會完全被顛覆。
慣用日期
cache 用，可排序。例如 JD。至於輸出要使用公元日期或是啥的，反正有紀年轉換工具，就隨意了。
標籤
例如「標題:」、「人:」、「事:」、「物:」等，將有關連的項目放在一起，也方便搜尋。
內容
事件或是紀錄的文件內容。可包括影音圖片、地圖或圖表等多媒體資料。
依據
對於古史，列出依據較容易對照。
參考資料
其他相關文獻的 link。
只是真要做出來，我想就算大部分工作能以機器處理，最後總是需要人工校對。這工作量可是很大的！
