ধর্মীয় উৎসব ও উপবাসের তারিখ নির্ধারণের নিয়ম

পঞ্জিকার কোনো তারিখে “আজ একাদশী”, “আজ জন্মাষ্টমী” বা “পারণ সকাল ৬:১২–৯:৩৮”—এই সিদ্ধান্ত শুধু তিথির নাম দেখে লেখা যায় না। তিথির শুরু–শেষ, স্থানীয় সূর্যোদয়–সূর্যাস্ত এবং নির্বাচিত ধর্মীয় পরম্পরার অগ্রাধিকার-নিয়ম একসঙ্গে পরীক্ষা করতে হয়।

জ্যোতির্বৈজ্ঞানিক গণনা ও ধর্মীয় নির্ণয়—দুটি স্তর

প্রথম স্তরে astronomical engine সূর্য ও চন্দ্রের longitude থেকে তিথির continuous timeline তৈরি করে। একইভাবে নক্ষত্র, যোগ, করণ, sunrise, sunset ও অন্যান্য event time নির্ণয় করা হয়।

দ্বিতীয় স্তরে festival rule engine প্রশ্ন করে—প্রয়োজনীয় তিথি কোন স্থানীয় সময়সীমায় উপস্থিত, দুই দিনে থাকলে কোন দিন অগ্রাধিকার পাবে, এবং ব্যতিক্রমী অবস্থায় tie-breaker কী হবে।

এই কারণে দুটি পঞ্জিকা একই তিথির শেষ সময় দেখিয়েও আলাদা উৎসব-দিন দিতে পারে। তাদের astronomy একই হলেও rule tradition আলাদা হতে পারে; আবার rule একই হলেও sunrise definition বা location আলাদা হতে পারে।

তিথি-ব্যাপ্তি কী?

সূর্য ও চন্দ্রের geocentric longitude-এর ব্যবধান প্রতি ১২° অতিক্রম করলে নতুন তিথি শুরু হয়। একটি তিথির গড় দৈর্ঘ্য প্রায় একদিনের কাছাকাছি হলেও চন্দ্রের পরিবর্তনশীল গতির কারণে এটি ২৪ ঘণ্টার সমান নয়। ফলে একটি তিথি:

• এক civil date-এর মাঝখানে শুরু হয়ে পরের date-এ শেষ হতে পারে;
• একটি স্থানীয় sunrise-কে স্পর্শ না-ও করতে পারে;
• পরপর দুটি sunrise-এ উপস্থিত থাকতে পারে;
• প্রয়োজনীয় মধ্যাহ্ন বা নিশীথে মাত্র অল্প সময়ের জন্য থাকতে পারে।

Festival rule-এ “ব্যাপিনী” বা presence বলতে নির্দিষ্ট reference interval-এ তিথির overlap বোঝানো হয়। শুধু দিনের যেকোনো সময়ে তিথিটি ছিল—এই তথ্য যথেষ্ট নয়।

Exact boundary-তে দ্বৈত গণনা এড়াতে software-এ অর্ধ-খোলা interval ব্যবহার করা ভালো। কোনো তিথি ঠিক মধ্যাহ্নের শুরুতে শেষ হলে সেটিকে আগের তিথির শেষ না নতুন তিথির শুরু হিসেবে ধরতে হবে—এই boundary policy-ও লিখিত থাকা প্রয়োজন।

প্রধান স্থানীয় কালসীমা

সব উৎসব sunrise-ব্যাপিনী নয়। ধর্মীয় গ্রন্থ, নিবন্ধ ও আঞ্চলিক পরম্পরায় বিভিন্ন reference time ব্যবহৃত হয়:

“মধ্যাহ্ন”কে সব ক্ষেত্রে 12:00 PM এবং “নিশীথ”কে 12:00 AM ধরা ভুল। এগুলো daylight বা night interval-এর স্থানীয় অংশ। ঋতু ও location অনুযায়ী clock time বদলায়।

ক্ষয় তিথি ও বৃদ্ধি তিথি

তিথির পরিচয় sunrise-ভিত্তিক করলে দুটি গুরুত্বপূর্ণ অবস্থা তৈরি হয়:

• ক্ষয় তিথি: একটি তিথি দুই sunrise-এর মাঝখানে শুরু ও শেষ হয়; কোনো sunrise-এ সেই তিথি থাকে না।
• বৃদ্ধি তিথি: একই তিথি পরপর দুটি sunrise-এ বর্তমান থাকে।

ক্ষয় হলে তিথিটি অদৃশ্য নয়—তার start/end instant থাকে এবং নির্দিষ্ট মধ্যাহ্ন, প্রদোষ বা নিশীথে উপস্থিত থাকতে পারে। বৃদ্ধি হলে দুই civil date-এ একই sunrise-tithi দেখা যায়, কিন্তু উৎসবের জন্য একটিকে বেছে নিতে হয়। সেই নির্বাচন সংশ্লিষ্ট vrata rule-এর ওপর নির্ভরশীল।

একাদশী উপবাস নির্ণয়ের সাধারণ কাঠামো

একাদশী নির্ণয় পঞ্জিকার সবচেয়ে rule-sensitive অংশগুলোর একটি। “একাদশী তিথি কোনো সময়ে ছিল”—এই কারণে উপবাস ঘোষণা করা যথেষ্ট নয়। সাধারণত আগের দশমী, অরুণোদয়, sunrise-এ একাদশীর উপস্থিতি, পরবর্তী দ্বাদশী এবং পারণের সুযোগ পরীক্ষা করতে হয়।

একটি transparent Ekadashi evaluator নিচের snapshot-গুলো নেবে:

1. পূর্বদিনের sunrise ও তিথি;
2. উপবাসের সম্ভাব্য দিনের অরুণোদয়;
3. সেই দিনের sunrise;
4. পরবর্তী দিনের sunrise;
5. দ্বাদশীর শুরু ও শেষ;
6. নক্ষত্র-নির্ভর মহাদ্বাদশী condition থাকলে সংশ্লিষ্ট নক্ষত্র।

গৌড়ীয় বৈষ্ণব নিয়মে অরুণোদয়ে দশমীর স্পর্শ থাকলে একাদশীকে অশুদ্ধ বা দশমী-বিদ্ধ হিসেবে বিবেচনা করে উপবাস পরের উপযুক্ত দিনে যেতে পারে। Smārta বা অন্য tradition-এর selection একই নাও হতে পারে। তাই software-এ একটিমাত্র boolean “IsEkadashi” দিয়ে সব community-এর ফল তৈরি করা উচিত নয়।

মহাদ্বাদশী ও ব্যতিক্রমী অবস্থা

কিছু অবস্থায় উপবাস একাদশী নামের civil day-এ না থেকে দ্বাদশীতে পালিত হয় এবং ফলটিকে মহাদ্বাদশী হিসেবে প্রকাশ করা হয়। এর কারণ হতে পারে তিথির বিশেষ বিন্যাস, একাদশীর বৃদ্ধি, দ্বাদশীর ক্ষয় অথবা tradition-নির্দিষ্ট নক্ষত্রযোগ।

গৌড়ীয় calendar literature-এ Unmilani, Trisprisha, Paksha-vardhini এবং নির্দিষ্ট নক্ষত্র-সম্পর্কিত মহাদ্বাদশীর পৃথক case আছে। এগুলো নামের তালিকা দিয়ে hard-code না করে input conditions-এর truth table হিসেবে লেখা নিরাপদ।

উদাহরণস্বরূপ, evaluator-এর trace এমন হতে পারে:

Candidate day: 2026-06-26
Arunodaya tithi: Ekadashi
Sunrise tithi: Ekadashi
Next sunrise tithi: Trayodashi
Dvadashi sunrise presence: No
Applied rule: Trisprisha-type Mahadvadashi
Fast: 2026-06-26
Parana: rule-selected Trayodashi interval

উপরের তারিখ ও label শুধু trace format-এর উদাহরণ; real output calculation থেকে আসবে। গুরুত্বপূর্ণ বিষয় হলো সিদ্ধান্তের কারণ সংরক্ষণ করা।

পারণের সময় কীভাবে নির্ধারিত হয়?

উপবাসের পরের দিন যেকোনো সময় আহার করলেই technically calendar parana নয়। ঘোষিত tradition অনুযায়ী পারণ window নির্ণয়ে সাধারণত নিচের সীমা বিবেচনা করা হয়:

• স্থানীয় sunrise-এর আগে পারণ নয়;
• দ্বাদশী উপস্থিত থাকলে তার শেষ হওয়ার আগে পারণকে অগ্রাধিকার;
• প্রযোজ্য হলে Hari-vāsara বা দ্বাদশীর নিষিদ্ধ প্রারম্ভিক অংশ অতিক্রম করা;
• অন্য শাস্ত্রীয় day-part limit থাকলে তার সঙ্গে intersection;
• মহাদ্বাদশী বা ক্ষয় দ্বাদশীতে আলাদা fallback rule।

Window-এর শুরু ও শেষ একই civil date-এ না-ও থাকতে পারে; DST transition থাকলে দুই endpoint-এর UTC offset-ও আলাদা হতে পারে। তাই পারণ compare করতে canonical instant ব্যবহার এবং display-তে local offset দেখানো উচিত।

উৎসবভেদে কোন reference time গুরুত্বপূর্ণ?

নিচের সারণিটি software design-এর একটি conceptual map। চূড়ান্ত production rule সংশ্লিষ্ট প্রামাণ্য গ্রন্থ ও নির্বাচিত tradition-এর specification অনুযায়ী যাচাই করতে হবে।

এই mapping-কে universal বিধান হিসেবে নয়, rule engine-এর routing table হিসেবে দেখতে হবে। কোনো উৎসবের Smārta, Vaiṣṇava, Śākta বা আঞ্চলিক ব্যাখ্যা আলাদা হলে প্রত্যেকটির জন্য আলাদা versioned rule set প্রয়োজন।

সম্প্রদায়ভেদ কেন স্পষ্ট করা জরুরি?

একই “বৈষ্ণব” label-ও সব সময় যথেষ্ট নির্দিষ্ট নয়। গৌড়ীয়, নিম্বার্ক, গোস্বামী বা অন্য regional tradition নির্দিষ্ট একাদশী, অরুণোদয়, নক্ষত্রযোগ ও পারণ priority-তে ভিন্ন specification ব্যবহার করতে পারে। Smārta result-ও অঞ্চল ও গ্রহণ করা nibandha অনুসারে বদলাতে পারে।

এই প্রকল্পে user-selectable বা page-specific rule profile রাখা যায়:

Result page-এ শুধু উৎসবের নাম নয়, rule profile name ও version দেখানো উচিত। Rule পরিবর্তন হলে পুরোনো HTML বা XML পুনরায় তৈরি করেও কোন version ব্যবহৃত হয়েছিল তা জানা যাবে।

স্থান ও timezone বদলালে উৎসবের দিনও বদলাতে পারে

তিথির global transition instant একই থাকলেও Kolkata, Dhaka ও New York-এর অরুণোদয়, sunrise, sunset, নিশীথ ও moonrise ভিন্ন। তাই একই rule set তিনটি শহরে চালিয়েও আলাদা civil date পাওয়া স্বাভাবিক।

বিশেষত boundary-sensitive অবস্থায় কয়েক মিনিটের পার্থক্যও সিদ্ধান্ত বদলাতে পারে:

• একাদশী অরুণোদয়ের ঠিক আগে বা পরে শুরু হওয়া;
• নবমী মধ্যাহ্নের মাঝে শেষ হওয়া;
• অষ্টমী নিশীথের শুরুতে শেষ হওয়া;
• অমাবস্যা স্থানীয় প্রদোষের মধ্যে প্রবেশ করা;
• দ্বাদশী sunrise-এর কিছুক্ষণ পর শেষ হওয়া।

অতএব festival list কখনো একটি headquarters city থেকে সব location-এ copy করা উচিত নয়। XML-এর fixed-date উৎসব এবং calculated lunar festival-ও আলাদা category হিসেবে রাখা দরকার।

Software rule engine কীভাবে সাজানো যায়?

প্রতিটি উৎসবের জন্য বড় if/else block লিখলে code দ্রুত দুর্বোধ্য হয়। পরিবর্তে shared astronomical facts এবং versioned rule definitions আলাদা রাখা যায়:

1. Ephemeris layer: সূর্য, চন্দ্র, তিথি, নক্ষত্র ও rise/set;
2. Day-boundary layer: sunrise, Arunodaya, Madhyahna, Pradosha, Nishitha;
3. Candidate layer: কোন কোন civil date rule পূরণ করতে পারে;
4. Tradition layer: purity, vyapini, priority ও exception;
5. Parana layer: fasting result থেকে পরবর্তী permitted interval;
6. Explanation layer: applied rule ও rejected candidate-এর কারণ।

FestivalDecision Evaluate(FestivalRule rule, LocalDayFacts day)
{
    var candidates = FindCandidateDays(rule, day);
    var qualified = ApplyPresenceTests(candidates, rule.ReferencePeriods);
    var selected = ApplyTraditionPriority(qualified, rule.ProfileVersion);
    return AddParanaAndTrace(selected, rule);
}

একই calculated facts থেকে একাধিক profile চালানো গেলে research page-এ side-by-side তুলনা করা যায়। এতে astronomical engine বদলানো ছাড়াই Smārta ও Vaiṣṇava result-এর rule difference দেখা সম্ভব।

শুধু তারিখ নয়—কারণও প্রকাশ করুন

ব্যবহারকারী যখন printed Panjika-এর সঙ্গে অমিল দেখেন, তখন “উৎসব ২৬ জুন” লেখা যথেষ্ট নয়। একটি সংক্ষিপ্ত applied-rule trace ভুল input, astronomy difference ও rule difference আলাদা করতে সাহায্য করে।

Research mode-এ আরও রাখা যায়:

• সব relevant event-এর UTC ও local time;
• তিথির start/end Julian Day;
• sunrise convention;
• timezone ও event-time offset;
• selected profile, version ও source note;
• প্রত্যাখ্যাত candidate day-এর কারণ।

Validation checklist

Festival engine-এর ordinary date-এর চেয়ে boundary case বেশি গুরুত্বপূর্ণ। Test suite-এ অন্তত নিচের পরিস্থিতি রাখা উচিত:

1. একাদশী অরুণোদয়ের এক মিনিট আগে ও পরে শুরু;
2. পরপর দুই sunrise-এ একাদশী;
3. দ্বাদশী কোনো sunrise স্পর্শ না করা;
4. পারণের আগে Hari-vāsara শেষ হওয়া;
5. দ্বাদশী sunrise-এর কয়েক মিনিট পর শেষ হওয়া;
6. অষ্টমী নিশীথের ঠিক boundary-তে শেষ;
7. নবমী এক দিনের মধ্যাহ্নে, অন্য দিনের sunrise-এ থাকা;
8. Kolkata, Dhaka ও New York-এ একই festival rule;
9. DST পরিবর্তনের দিনে reference period;
10. ক্ষয় ও বৃদ্ধি তিথির calendar-grid display;
11. fixed XML festival ও calculated festival duplicate হওয়া;
12. একই event-এর দুই tradition profile-এ expected difference।

Regression test-এর expected result-এর সঙ্গে শুধু date নয়, applied rule code এবং key snapshots-ও সংরক্ষণ করা উচিত। এতে code refactor-এর পরে ভুল কারণে একই date পাওয়া গেলেও test ধরতে পারবে।

উপসংহার

ধর্মীয় উৎসব ও উপবাসের দিন নির্ধারণ একটি বহুস্তরীয় প্রক্রিয়া। Astronomy তিথি ও নক্ষত্রের timeline দেয়; স্থানীয় sunrise, Arunodaya, Madhyahna, Pradosha, Nishitha ও moonrise ritual boundary তৈরি করে; আর নির্বাচিত ধর্মীয় tradition সেই boundary-তে presence ও priority পরীক্ষা করে চূড়ান্ত দিন নির্বাচন করে।

ক্ষয় বা বৃদ্ধি তিথি, দশমী-বিদ্ধ একাদশী, মহাদ্বাদশী এবং সংক্ষিপ্ত পারণ window-এর মতো case-গুলো দেখায় কেন একটি সাধারণ date lookup যথেষ্ট নয়। Rule engine-কে versioned, location-aware এবং explanation-producing হতে হবে।

সৎ পঞ্জিকা তাই শুধু “কবে” বলে না—“কোন স্থান, কোন গণনাপদ্ধতি, কোন রীতি এবং কোন নিয়মে” সেই দিন নির্বাচিত হয়েছে তাও জানায়। এই transparency ধর্মীয় ব্যবহারকারী, গবেষক এবং software developer—সবার জন্য ফলকে যাচাইযোগ্য করে।

তথ্যসূত্র ও আরও পাঠ

1. Kāśīnātha Upādhyāya, Dharma Sindhu; কাল, তিথি, ব্রত ও উৎসব-নির্ণয় অংশ। একটি digitized সংস্করণ: Internet Archive.
2. Kanchi Kamakoti—Essence of Dharma Sindhu, book index.
3. Kamalākara Bhaṭṭa, Nirṇaya Sindhu; vrata ও tithi-nirṇaya সংক্রান্ত নিবন্ধ।
4. Gopāla Bhaṭṭa Gosvāmin, Hari-bhakti-vilāsa; Vaiṣṇava vrata ও Ekādaśī আলোচনার প্রামাণ্য উৎসগুলোর একটি।
5. GCAL—Vaisnava Events Calculation; Ekādaśī, Mahādvādaśī ও Parana algorithm-এর technical summary.
6. GCAL for Windows source and documentation archive.
7. ISKCON GBC 1989 resolutions; Calendar Research Committee-এর ঐতিহাসিক উল্লেখ।
8. সূর্য সিদ্ধান্ত পঞ্জিকা প্রকল্পের Ekādaśī, Mahādvādaśī, Parana, Janmāṣṭamī, Rāma-navamī এবং নিশিপালন implementation notes.