Chinese almanac · lunar ⇄ solar conversion · zodiac animals and star signs
Today’s almanac (do’s and don’ts, clashes, presiding deity, mansions, lucky directions, taboos, double-hours, date picking), Gregorian/Lunar conversion with reverse leap-month lookup, quick zodiac and star-sign tables and a Spring Festival countdown; calendar and almanac data are computed in your browser by the self-hosted astronomy library lunar-javascript, matching the official calendar tables, with no network and nothing uploaded.
公历日期 → 农历年月日、生肖、干支、大小月
支持 1900 年 ~ 2100 年。生肖与干支年按农历年（正月初一）切换，与八字命理按立春切换的口径可能不同，年初出生的人两种口径会不一样。
老黄历、农历与星座：几条最容易被搞错的常识
老黄历上的「宜」「忌」不是算出来的，是查表查出来的。通书把一年里每一天的宜忌，按「月令（当月月建，即月干支）+ 日干支」的组合事先编成表，所以同一天的宜忌是固定的几十个事项，而不是根据某个人、某件事推出来的。本页的宜忌同样来自算法库里的这张表。由此可以推出两件事：① 宜忌与「你是谁」无关——表里不含八字、不含主事人生辰，对所有人都一样；真正个性化的是合婚、择时这类需要生辰的环节，那是另一套体系，本页不做。② 同一天不同网站给出不同宜忌，最常见的原因是月令换代的流派不同：月令在交节（立春、惊蛰、清明……）时换代，一派按交节当天整日就换（通书与纸质黄历的通行口径，本页采用），另一派按交节的精确时刻换——分歧只出现在交节当天，2026 年实测 365 天里只有 12 天。本页在交节日会把两种月令都标出来，而不是替你选一个。
冲煞、值神、星宿、彭祖百忌分别是什么。「冲」是当日地支相冲的生肖（如戌日冲辰，冲龙），「煞」是当日所煞的方位；「值日」是建除十二值星（建、除、满、平、定、执、破、危、成、收、开、闭），「值神」是当日轮值的十二神，分黄道（吉）与黑道（凶）；「二十八宿」是当日轮值的星宿，各有吉凶与歌诀；「吉神方位」给的是喜神、财神、福神、阳贵神、阴贵神的方位；「彭祖百忌」是干支日对应的两句禁忌口诀（如「甲不开仓」）；「胎神占方」是传统上孕妇居所与动土方位的讲究；「时辰吉凶」则把一天切成十二个时辰，各按自己的时干支给出值神与宜忌——所以同一天里有的时辰吉、有的时辰凶。这些都属于传统民俗与择日体系，没有统一的国家标准，不同流派与不同版本的历书结论可能不同；本页如实呈现算法库的查表结果并标注口径，供参考，不构成任何决策建议。
择日为什么不能只看「宜」这一栏。本页的择日只做一件事：在给定区间里挑出「宜」中含你所选事项、且「忌」中不含该事项的日子。真实的择日还要看主事人生辰八字、方位、时辰，乃至家族习俗——本页明确不做这些，也不给「最吉利的那一天」这种结论，只把表里的客观事实列出来供你自己判断。
农历不是"阴历"，它是阴阳合历，所以必须有闰月。农历的月份严格跟着月相走（朔为初一、望在十五前后），一个朔望月平均约 29.53 天，十二个月只有约 354 天，比回归年（约 365.24 天）少约 11 天。如果放任不管，不出几年春节就会跑到夏天去。古人的解法是让月份跟着月亮、年份跟着太阳：每 19 个回归年插入 7 个闰月（19 年 7 闰，19 个回归年 ≈ 235 个朔望月），闰月插在没有"中气"的那个月之后，所以闰四月、闰六月、闰十一月都会出现。这也解释了为什么农历生日换算成公历每年都不一样，前后能差一个多月。
大月 30 天、小月 29 天，不是固定的。农历每个月的天数取决于这个朔望月实际有多长（29.53 天上下浮动），所以哪个月是大月、哪个月是小月，年年不同，必须查历。本页的大小月直接取自天文算法库给出的每个农历月的天数，与官方历表的口径一致。这直接影响农历生日：腊月三十出生的人，遇到只有 29 天的年份就没有"三十"这一天，民间通常提前到二十九过，这也是本页在"农历转公历"里遇到不存在的日期时给出最接近合法日期的原因。
生肖和干支年有两种口径，年初出生的人会"差一个属相"。本页统一按农历年（正月初一）切换生肖与干支年：2026 年 2 月 16 日还是乙巳（蛇）年腊月廿九，2 月 17 日（正月初一）起才是丙午（马）年。但八字命理按立春切换，立春通常在 2 月 3–5 日，比春节早半个月左右，所以在"立春之后、春节之前"出生的人，两种口径会给出不同的属相与干支年；此外还有少数地区按公历 1 月 1 日切换的通俗说法。本页按农历年给结果并明确标注口径，填表、算八字这类用途请以对方要求的口径为准。
星座分界为什么每年会差一天。星座是按太阳在黄道上的位置（节气）划分的，分界点落在每年 20–23 日之间，随年份浮动：水瓶座从 1 月 20 日前后开始，摩羯座到 1 月 19 日前后结束。国际上流传的这套日期表本身就有多个版本，个别星座的起始日在不同资料里能差一天，所以"我到底是摩羯还是水瓶"这种边界日，不同网站给出不同答案并不奇怪。本页采用最通行的一套固定分界并把日期区间一起显示出来，落在分界当天时请把它当作"两套说法都说得通"来看待，而不是唯一答案；闰年 2 月 29 日按双鱼座处理（2 月 29 日在 2 月 19 日 – 3 月 20 日区间内）。
为什么这里要自己带一个天文算法库，而不是用浏览器自带的农历。现代浏览器确实内置了 ICU/CLDR 国际化数据库，标准 API Intl.DateTimeFormat 也支持 zh-CN-u-ca-chinese 这个历法扩展。但拿它和香港天文台官方「公曆與農曆日期對照表」逐日核对后发现，它并不是"总差一天"，而是偶发错误：2027 年它把春节算成 02-07，官方历表是 02-06；2030 年它把春节算成 02-02，官方历表是 02-03。农历差一天就是错的（查生日、算春节、办喜事都用它），所以本页改用自托管的天文算法库 lunar-javascript（MIT 许可）在你的浏览器里现算，它的结果与官方历表一致（2027 = 02-06、2030 = 02-03、2034 = 02-19、2033 年闰十一月）。它同样不需要联网，也就同样不需要把你输入的日期交给服务器。
为什么不上传到服务器。农历换算不需要任何后端能力：算历的算法库已经随页面一起下发到你的浏览器，全部计算都在本地完成。所以本页把全部计算放在你的设备上执行，你输入的生日、婚期、任何日期都不会离开浏览器（打开开发者工具的 Network 面板可以看到整页没有任何提交请求）。页面不写 localStorage、不写 cookie、不把输入写进网址，也不读取你的姓名或手机号——你算过什么，服务器一无所知，刷新后不留痕迹。
FAQ
The do's and don'ts come from tables precompiled in the traditional almanac: look up month-stem-branch plus day-stem-branch, and the same day yields the same fixed set of a few dozen items - independent of who you are or what you plan, and no birth-chart involved. When sites disagree on the same day, the usual cause is two schools of when the month's stem-branch changes: one switches on the whole day of the solar-term boundary (the mainstream almanac and paper-calendar practice, used by this page), the other switches at the exact moment of the boundary - they differ only on the 12 boundary days of the year (measured for 2026: 12 out of 365). On a boundary day this page shows both month readings and labels which one it used.
Because there are two conventions for the switching point. This page switches by the lunar year: before Spring Festival you belong to the previous lunar year, and from Spring Festival day itself the new zodiac year begins. Bazi astrology switches at Start of Spring, which usually falls about half a month before Spring Festival - so people born 'after Start of Spring but before Spring Festival' get different signs under the two conventions. Pick the convention that fits your use; results here are labeled as by the lunar year.
Lunar months are long (30 days) or short (29) depending on the actual length of that lunation, so the 30th of the 12th month does not exist every year. When the 12th month has only 29 days, New Year's Eve falls on the 29th (for example 5 February 2027 is the 29th of the 12th month). On this page, entering a non-existent date in 'lunar to Gregorian' clearly says so and offers the nearest legal date (usually the 29th of the same month).
A lunar year is about 354 days while a Gregorian year is 365 - an 11-day gap per year. To catch the Sun back up, the lunar calendar inserts a leap month every two or three years (7 in 19), and after insertion the date jumps back. So the same lunar birthday wanders between roughly mid-January and late February on the Gregorian side - that is normal, not a computation error.
The lunar calendar is computed by the self-hosted astronomy library lunar-javascript (MIT), consistent with the Hong Kong Observatory's official Gregorian-lunar date tables; the almanac's do's/don'ts, clashes, presiding spirits and lodges are table lookups from the same library. Extreme historical or future years, and leap months whose placement is debated, may differ from official ephemerides - for consequential uses (weddings, rites, legal documents) defer to the officially published almanac compiled by the Purple Mountain Observatory. The almanac's conclusions are traditional folklore, and disagreement between almanac editions is the norm; this page faithfully presents what the library computes and labels the convention used.
The page queries the astronomy library directly for the first day of the first lunar month (Spring Festival) of that lunar year and subtracts today by calendar days. When today is Spring Festival it shows 0. The difference is compared as local calendar days, not by millisecond arithmetic - so it is unaffected by daylight-saving shifts like China's 1986-1991 experiment.
No. Both lunar conversion and almanac lookup need only the library shipped with the page; all computation runs in your browser. The page sends no submit request, writes no localStorage, no cookie, and never puts your input into the URL. Which day you looked up is completely unknown to the server.