最近同事在問,還要農曆,弄了一陣子才發現,果然是坑。
網路上的VBA弄沒很懂,而且可能是版本太舊之類,反正VBA都跑不東西來。
而且依照VBA發文串來看,之後仍有些日子跑掉的回文。看起來時間花的不划算。

只有簡單粗暴地用容量來解決問題了,網路上可以找到國曆與農曆的直接對照表txt(希望他全是對的),直接匯入對照尋找。

(自動生成方式: 生成當月1日數字碼後,利用weekday來回歸對齊星期日的位置。)
(再來判別是否符合當月,非當月就留白。在VLOOKUP查找對應的農曆)

因為對照表數據挺多,大約就砍到 2020年至2100年,整個檔案約還有1.3mb,不過現在已經沒有人在欠容量了。
這樣只要改年與月,就可以印出一張月曆了。
oxa9615 wrote:
(再來判別是否符合當月,非當月就留白。在VLOOKUP查找對應的農曆)

因為對照表數據挺多,大約就砍到 2020年至2100年,整個檔案約還有1.3mb,不過現在已經沒有人在欠容量了。
這樣只要改年與月,就可以印出一張月曆了


2100 年?
印象 農曆 有點奇怪,能算出未來10年,應該滿厲害.

以前免費小app,專印月曆,
大概也1~2MB.

所以Excel 變自動更新時,免費 安裝試用.
oxa9615
的確沒有完美公式可以長期轉換農曆,大多幾年後都會出現點小問題。選擇用無腦一點的方式,不過那參照表應該也是公式跑出來的。
ForexAndrew wrote:
2100 年?
印象 農曆 有點奇怪,能算出未來10年,應該滿厲害.


中研院的網頁可以算到2101
所以應該是沒有問題
西元元年2月11日至2101年1月29日
兩千年中西曆轉換

ai
1. 算法 vs. 數據表 (Lookup Table)
純算法 (公式法): 由於月球運行軌道受太陽、地球及其他行星引力干擾(如攝動運動),農曆的朔望月長度並不固定(約 29.27 到 29.83 天)。如果僅用一個平均數值去算,累積幾年後一定會產生 1 到 2 天的誤差。
數據表法 (推薦): 目前絕大多數穩定(如 lunar-calendar 或 lunar-python)的程式庫,都是根據天文台發布的萬年曆數據 (Ephemeris) 寫死在程式碼中。只要數據源準確(如參考紫金山天文台),在預設的時間範圍內(通常是 1901–2100 年)是零誤差的。
ForexAndrew
當年,約民88年前後,我有看 專家討論 過這議題.. 當時專家的對應表只到民99年. 未來約10幾年. 現在就算進步,也不可能是未來75年這麼久.
ForexAndrew
所以要是能 準個 未來10年就是專家級了!! (想計算10年後,我猜你們誤差越來越大!!)
唬唬生瘋 wrote:
中研院的網頁可以算到2101
所以應該是沒有問題
西元元年2月11日至2101年1月29日
兩千年中西曆轉換

ai
1. 算法 vs. 數據表 (Lookup Table)
純算法 (公式法): 由於月球運行軌道受太陽、地球及其他行星引力干擾(如攝動運動),農曆的朔望月長度並不固定(約 29.27 到 29.83 天)。如果僅用一個平均數值去算,累積幾年後一定會產生 1 到 2 天的誤差。
數據表法 (推薦): 目前絕大多數穩定(如 lunar-calendar 或 lunar-python)的程式庫,都是根據天文台發布的萬年曆數據 (Ephemeris) 寫死在程式碼中。只要數據源準確(如參考紫金山天文台),在預設的時間範圍內(通常是 1901–2100 年)是零誤差的。


有算,不一定算對.
農曆的特例 ai 可能不夠熟悉, 解釋略對一半,也錯一些,
(沒想到20幾年沒變,可以錯這麼多年)
大家 不要急者用這些理論去寫計算式,會一定幾個月後就錯誤一堆了!!!


我當年win95~XP,寫行事曆 ActionXP/ActionV,
農曆部分,是找專家寫的模組, 當時作者介紹,有額外 感謝該作者.
(整支app 約要用到別人模組的,大概就2~3個作者.)

你們自行網路再找找..
或者 自行驗證看看 幾個月後,還準不準,搞不好就誤差一堆,不用10年後啦.
文章分享
評分
評分
複製連結

今日熱門文章 網友點擊推薦!