潘昌迦的计算方式，逐步拆解，完全公开

大多数潘昌迦网站只展示数字，却不告诉你数据从何而来。你只能相信幕后有人做对了。我们的做法截然相反：整个计算过程逐步公开，你可以随时跟踪，也可以在我们出错时纠正我们。

这不是为了炫耀技术，而是关乎信任。当Toronto的Rahu Kalam与你母亲在Chennai的相差十分钟时，唯一行得通的解释，是能追溯到精确输入数据和透明公式的那一个。否则只是在猜测，而当涉及你认真对待的事情时，猜测是不够的。

以下我们逐层介绍计算过程，从日出到节日日期，提供精确的算法和常数。文字写法让你不需要天文学背景也能跟上，同时包含足够的细节让工程师能够验证每一步。

一切从太阳开始。日出和日落决定白昼时段，进而决定Rahu Kalam、Yamagandam、Kuligai、Abhijit Muhurtam和Gowri Panchangam。太阳位置计算有误，其余所有计算也会随之出错。

我们使用NOAA太阳计算器——与US National Oceanic and Atmospheric Administration公开太阳计算器所用的算法相同。它根据儒略日数及观测者的经纬度，计算太阳的黄经、赤纬、时差方程以及日出时的时角。

月球位置对Tithi、Nakshatra、Yoga和Karana至关重要——这是潘昌迦五要素中除星期几以外的四项。月球运行速度快：每天约13°，而太阳仅约1°。因此，精确的潘昌迦需要一个好的月球模型。

我们使用Jean Meeus《天文算法》第47章——月球黄经的完整60项ΣL级数。这与严谨的天文历书和天文馆软件所用的模型相同。该级数对月球轨道所有已知摄动的60个调和项求和。

结果是月球的视黄经（度数，沿黄道0°–360°）。结合太阳黄经得到Tithi（月日角距）；结合阿亚那姆沙得到Nakshatra（月球的恒星位置）。

Tithi取决于日月之间的角度，与坐标系无关。但Nakshatra、Yoga和Rashi需要恒星坐标：相对于恒星的位置，而非春分点。

回归坐标与恒星坐标之间的差值称为阿亚那姆沙。我们使用Lahiri（Chitrapaksha）——印度政府自1956年起官方采用的标准，也是泰米尔潘昌迦传统中最广泛使用的。我们的模型为线性模型，以J2000历元为锚点。

Rahu Kalam、Yamagandam和Kuligai均基于同一原理：将白昼（日出到日落）均分为八段，根据星期几选取其中一段。这是纯算术计算，但精确结果依赖于正确的日出日落时间。

Abhijit Muhurtam是白昼15个等分Muhurta时段中的第8段，精确以正午为中心。计算简单，但需要准确的日出日落时间：

• 正午 = （日出 + 日落）/ 2
• 半Muhurta = （日落 − 日出）/ 30
• Abhijit开始 = 正午 − 半Muhurta
• Abhijit结束 = 正午 + 半Muhurta

在Chennai一月（日出06:35，日落18:01），Abhijit时窗约为11:55至12:41，约46分钟。在Copenhagen六月，白昼长得多，时窗超过一小时。

节日使用两套完全不同的来源体系。主要固定节日（Pongal、Deepavali、Thai Pongal、Puthandu）由编辑团队精心整理：手动录入日期，对照官方历法出版物双重核验，数据涵盖2026至2029年。

每月的例行斋戒日（Amavasai、Pournami、Ekadasi、Pradosham、Sashti、Karthigai等）根据Tithi和Nakshatra实时计算，方法与上文完全相同。计算时始终以Chennai的日出作为参考点，即使你身处London。为什么？因为节日日期由圣地日出时生效的Tithi决定，而非你当地的日出。

整个计算引擎用纯TypeScript编写。它不导入任何外部天文库，不调用任何API，也不查询任何数据库。同一段代码在页面构建时在服务器上运行，也在你选择新城市时在浏览器中运行。结果是确定性的：相同的输入，在任何地方，任何时候，都会得到完全相同的输出。

这个选择是有意为之的。当计算完全自给自足时，就不存在会宕机的服务器，不存在会过期的API密钥，也不存在第三方变更悄悄改变我们数字的可能。这意味着你或任何人都可以通过查看开源代码来验证每一个数字。

本日历专注于能以天文精度计算的内容。但潘昌迦世界中有些话题我们有意不纳入计算，因为它们要么需要主观判断，要么因流派而异：

• 婚礼和仪式的吉时（Muhurtham）选定——需要星盘解读，我们不对其自动化。
• 大夏期（Dasha）和行星力量——依赖占星传统，而非天文学。
• 有地方差异的神庙节日——由各庙的传统决定，并非集中统一。

与其展示一个我们无法担保的数字，不如什么都不显示。这是整个日历的创立原则。