অরুণোদয়, মধ্যাহ্ন, প্রদোষ ও নিশীথ: উৎসবের Rule-Moment কীভাবে নির্ধারিত হয়?

একই local date-এ sunrise-এর সময় দশমী, দুপুরে একাদশী এবং রাতে দ্বাদশী হতে পারে। Header-এ দেখানো sunrise-tithi সঠিক হলেও সেটি মধ্যাহ্ন-ব্যাপিনী বা নিশীথ-ব্যাপিনী উৎসবের সিদ্ধান্ত দিতে পারে না। নির্ভরযোগ্য পঞ্জিকা তাই প্রথমে ধারাবাহিক astronomical timeline তৈরি করে, পরে tradition-specific rule-moment-এ সেই timeline পরীক্ষা করে।

Civil date আর ritual rule-moment এক নয়

“৮ অক্টোবর উৎসব”—এটি গণনার input নয়; এটি rule প্রয়োগের পর পাওয়া display date। Calculation-এর input হলো:

• স্থানীয় latitude, longitude ও time zone;
• নির্বাচিত sunrise/sunset profile;
• তিথি ও নক্ষত্রের absolute start/end instants;
• উৎসবের rule profile বা পরম্পরা;
• প্রয়োজনীয় moment—sunrise, অরুণোদয়, মধ্যাহ্ন, প্রদোষ, নিশীথ ইত্যাদি;
• একাধিক দিনের মধ্যে নির্বাচন করার priority ও tie-break rule।

অতএব festival service-এর কাজ “আজকের তিথির নাম” মিলিয়ে label বসানো নয়। তাকে candidate local days তৈরি করে প্রত্যেক দিনের rule interval-এ তিথির overlap মাপতে হবে, তারপর declared rule অনুসারে সেরা দিন নিতে হবে।

একটি canonical solar day object

Daily report, Bengali calendar ও festival engine যেন আলাদা আলাদা sunrise calculate না করে। একটি shared SunDayResult থেকে চারটি মৌলিক instant নিন:

এখানে interval-এর notation [start, end): start অন্তর্ভুক্ত, end বাদ। ফলে কোনো তিথি যদি ঠিক interval-end-এ শুরু হয়, তাকে আগের interval-এর overlap বলা হবে না। Boundary case-এ double counting এড়াতে এই নিয়ম সব service-এ এক রাখুন।

আগের প্রবন্ধে নির্ধারিত project profile—Sun center, no refraction—এই চারটি instant-এর ভিত্তি। অন্য sunrise profile ব্যবহার করতে চাইলে আলাদা version ID এবং আলাদা cache key ব্যবহার করতে হবে।

Fixed duration ও proportional division গুলিয়ে ফেলবেন না

দিন-রাত ঠিক ১২ ঘণ্টা হলে proportional মুহূর্ত ৪৮ মিনিট হয়। কিন্তু শীত-গ্রীষ্ম বা উচ্চ latitude-এ daylight ও night length বদলে যায়; তাই মধ্যাহ্ন বা নিশীথের জন্য সবদিন fixed ৪৮ মিনিট hard-code করা যুক্তিসঙ্গত নয়। অন্যদিকে project-এর অরুণোদয় rule ইচ্ছাকৃতভাবেই fixed চার দণ্ড বা ৯৬ মিনিট।

সূর্যোদয় থেকে সূর্যাস্ত: দিনের পাঁচ ভাগ

Ritual day-কে পাঁচ সমান অংশে ভাগ করলে:

এই interval-গুলো clock-এর স্থির ৬:০০–৮:২৪ বা ১১:০০–১৩:০০ নয়। Dhaka, Kolkata ও New York-এ একই তারিখে এবং একই time zone-এর ভিন্ন longitude-এও সূর্যোদয়-সূর্যাস্তের কারণে boundary বদলাবে।

মধ্যাহ্ন: শুধু clock noon নয়

মধ্যাহ্ন হলো daylight-এর তৃতীয় পঞ্চমাংশ:

এটি civil clock-এর ১২টা নয়। Daylight midpoint apparent solar noon-এর কাছাকাছি হলেও একই জিনিস বলে ধরে নেওয়া উচিত নয়; actual solar transit চাইলে ephemeris transit function দিয়ে আলাদাভাবে solve করতে হবে। Festival policy যদি “মধ্যাহ্ন-ব্যাপিনী তিথি” বলে, তবে পুরো Madhyahna interval-এর সঙ্গে তিথির overlap পরীক্ষা করুন। যদি source “মধ্যাহ্ন-মুহূর্তে তিথি” বোঝায়, তবে midpoint-state পরীক্ষা হতে পারে। এই দুটো predicate একই নয়।

উদাহরণ: রামনবমী rule profile-এ নবমী দুই candidate দিনের মধ্যাহ্ন স্পর্শ করলে কোন দিনের overlap বেশি, পরের তিথি কোন সময় শুরু হয় এবং tradition-এর tie-break কী—সবগুলো declared হতে হবে। শুধু sunrise-এ নবমী দেখে সিদ্ধান্ত নিলে মধ্যাহ্ন-ব্যাপ্তির তথ্য হারায়।

অরুণোদয়: একটি fixed evaluation instant

এই project-এর বৈষ্ণব rule profile-এ অরুণোদয় selected project sunrise-এর ঠিক ৯৬ মিনিট আগে:

এটি civil dawn বা Sun altitude −৬° হওয়ার astronomical event নয়। একাদশী rule-এ প্রশ্ন হতে পারে—অরুণোদয়ে একাদশী ইতিমধ্যে শুরু হয়েছে, নাকি দশমী তখনও চলছে? তাই sunrise header-এর তিথি যথেষ্ট নয়; StateAt(arunodaya) আলাদাভাবে করতে হবে।

Smārta, Vaiṣṇava, Nimbārka বা অন্য পরম্পরার পূর্ণ একাদশী সিদ্ধান্তে sunrise, অরুণোদয়, তিথিক্ষয়/বৃদ্ধি, দ্বাদশী ও pāraṇa window-র আরও শর্ত থাকে। অরুণোদয় একটি input moment—একাই সম্পূর্ণ একাদশী algorithm নয়।

প্রদোষ: একটি universal hard-coded interval নয়

প্রদোষের সংজ্ঞা বিভিন্ন গ্রন্থ, অঞ্চল ও ব্যবহারিক tradition-এ একরকমভাবে প্রকাশিত হয় না। একটি rule source সূর্যাস্তের পর তিন মুহূর্তকে প্রদোষ বলে; অন্য ব্যাখ্যায় রাত্রির প্রথম পঞ্চমাংশ, ছয় ঘটিকা বা অন্য sunset-centered interval ব্যবহৃত হতে পারে। তাই engine-এ PradoshaPolicy বাধ্যতামূলক হওয়া উচিত।

public sealed class PradoshaPolicy
{
    public string Id { get; set; }
    public string Authority { get; set; }
    public PradoshaMode Mode { get; set; }
    public int NightMuhurtaCount { get; set; }
    public int FixedMinutesAfterSunset { get; set; }
}

public enum PradoshaMode
{
    ProportionalNightMuhurtas,
    ProportionalFirstNightFifth,
    FixedMinutesAfterSunset
}

ধর্মসিন্ধু-ভিত্তিক একটি illustrative profile:

এটি example profile, সব tradition-এর জন্য universal ঘোষণা নয়। Printed Panjika যদি fixed ছয় ঘটিকা ব্যবহার করে, তার জন্য আলাদা policy ID দিন; পুরোনো profile-এর meaning বদলে দেবেন না। প্রদোষব্রতের candidate day নির্বাচন করতে Trayodaśī interval-এর সঙ্গে দুই দিনের configured Pradosha overlap তুলনা করতে হতে পারে।

নিশীথ: local night-এর অষ্টম মুহূর্ত

সূর্যাস্ত থেকে পরবর্তী সূর্যোদয় পর্যন্ত রাত্রিকে ১৫ সমান মুহূর্তে ভাগ করলে অষ্টম মুহূর্তটি রাতের মধ্যভাগে থাকে:

Zero-based fraction-এ Nishitha হলো [7/15, 8/15) night interval। এর midpoint সূর্যাস্ত ও পরবর্তী সূর্যোদয়ের ঠিক মাঝখানে। এটি civil midnight 12:00 AM নয় এবং time-zone meridian, longitude ও ঋতু অনুযায়ী clock time বদলায়।

Janmāṣṭamī profile-এ Kṛṣṇa Aṣṭamī নিশীথ স্পর্শ করছে কি না, এবং কোনো tradition-এ Rohiṇī nakṣatra-ও একই interval-এ বা midpoint-এ উপস্থিত কি না—এগুলো পৃথক predicate। Mahāśivarātri বা night-pūjā rule-এও Nishitha প্রাসঙ্গিক হতে পারে, কিন্তু উৎসবভেদে tie-break এক নয়।

তিথি-ব্যাপ্তি: উপস্থিতি শুধু true/false নয়

ধরা যাক rule interval R এবং তিথির interval T। তাদের overlap:

Rule source-এর ভাষা অনুযায়ী বিভিন্ন predicate লাগতে পারে:

AnyOverlap আর AtMidpoint এক নয়। Aṣṭamī Nishitha-এর প্রথম পাঁচ মিনিটে শেষ হলে interval স্পর্শ করেছে, কিন্তু midpoint-এ নেই। কোনটিকে উৎসবের জন্য গ্রহণ করা হবে তা ঐতিহ্যগত rule নির্ধারণ করবে—programmer-এর অনুমান নয়।

উৎসবভেদে rule-moment-এর উদাহরণ

এই table conceptual—প্রতিটি observance-এর পূর্ণ সিদ্ধান্তে আরও lunar month, pakṣa, weekday, nakṣatra, saṅkrānti বা regional condition থাকতে পারে। তাই একটি generic “festival by tithi” function-এর বদলে composable rules এবং উৎসব-নির্দিষ্ট policy ব্যবহার করা ভালো।

C# 5/.NET Framework-compatible interval engine

প্রথমে instant ও interval-কে absolute time-এ compare করুন:

public sealed class RuleInterval
{
    public string Id { get; set; }
    public DateTimeOffset Start { get; set; }
    public DateTimeOffset End { get; set; }

    public DateTimeOffset Midpoint
    {
        get { return RuleMath.AtFraction(Start, End, 1, 2, null); }
    }

    public bool Contains(DateTimeOffset instant)
    {
        DateTime utc = instant.UtcDateTime;
        return utc >= Start.UtcDateTime && utc < End.UtcDateTime;
    }
}

public enum PresenceRequirement
{
    AtStart,
    AtMidpoint,
    AnyOverlap,
    FullCoverage,
    MajorityOverlap
}

Fraction helper local wall-clock ticks নয়, UTC span ভাগ করবে:

public static class RuleMath
{
    public static DateTimeOffset AtFraction(
        DateTimeOffset start,
        DateTimeOffset end,
        int numerator,
        int denominator,
        TimeZoneInfo zone)
    {
        if (denominator <= 0) throw new ArgumentOutOfRangeException("denominator");
        if (numerator < 0 || numerator > denominator)
            throw new ArgumentOutOfRangeException("numerator");

        DateTimeOffset startUtc = start.ToUniversalTime();
        DateTimeOffset endUtc = end.ToUniversalTime();
        if (endUtc <= startUtc) throw new ArgumentException("end must follow start");

        long spanTicks = (endUtc - startUtc).Ticks;
        long partTicks = (long)Math.Round(
            spanTicks * ((double)numerator / denominator),
            MidpointRounding.AwayFromZero);

        DateTimeOffset valueUtc = startUtc.AddTicks(partTicks);
        return zone == null ? valueUtc : TimeZoneInfo.ConvertTime(valueUtc, zone);
    }

    public static TimeSpan Overlap(RuleInterval a, RuleInterval b)
    {
        DateTime start = a.Start.UtcDateTime > b.Start.UtcDateTime
            ? a.Start.UtcDateTime : b.Start.UtcDateTime;
        DateTime end = a.End.UtcDateTime < b.End.UtcDateTime
            ? a.End.UtcDateTime : b.End.UtcDateTime;
        return end > start ? end - start : TimeSpan.Zero;
    }
}

Canonical day থেকে rule intervals:

public static RuleInterval BuildMadhyahna(
    SunDayResult sun, TimeZoneInfo zone)
{
    return new RuleInterval
    {
        Id = "madhyahna-day-third-fifth-v1",
        Start = RuleMath.AtFraction(sun.Sunrise, sun.Sunset, 2, 5, zone),
        End = RuleMath.AtFraction(sun.Sunrise, sun.Sunset, 3, 5, zone)
    };
}

public static RuleInterval BuildNishitha(
    SunDayResult sun, TimeZoneInfo zone)
{
    return new RuleInterval
    {
        Id = "nishitha-night-eighth-muhurta-v1",
        Start = RuleMath.AtFraction(sun.Sunset, sun.NextSunrise, 7, 15, zone),
        End = RuleMath.AtFraction(sun.Sunset, sun.NextSunrise, 8, 15, zone)
    };
}

Midpoint property-তে zone null হলে UTC instant ফেরে; display-এর সময় selected zone-এ convert করুন। Business rule-এ formatted time string compare করবেন না।

Presence evaluator:

public static bool IsPresent(
    RuleInterval stateInterval,
    RuleInterval ruleInterval,
    PresenceRequirement requirement)
{
    TimeSpan overlap = RuleMath.Overlap(stateInterval, ruleInterval);
    TimeSpan ruleLength = ruleInterval.End.UtcDateTime
        - ruleInterval.Start.UtcDateTime;

    switch (requirement)
    {
        case PresenceRequirement.AtStart:
            return stateInterval.Contains(ruleInterval.Start);
        case PresenceRequirement.AtMidpoint:
            return stateInterval.Contains(ruleInterval.Midpoint);
        case PresenceRequirement.AnyOverlap:
            return overlap > TimeSpan.Zero;
        case PresenceRequirement.FullCoverage:
            return overlap == ruleLength;
        case PresenceRequirement.MajorityOverlap:
            return overlap.Ticks * 2L > ruleLength.Ticks;
        default:
            throw new ArgumentOutOfRangeException("requirement");
    }
}

তিথির timeline থেকে একটি RuleInterval বানাতে start ও end transition instants লাগবে। Daily display-তে শুধু “একাদশী রাত ১০:১৪ পর্যন্ত” string থাকলে overlap calculation করা যাবে না; raw instants model-এ রাখুন, string কেবল renderer বানাবে।

প্রতিটি সিদ্ধান্ত ব্যাখ্যাযোগ্য করুন

একটি festival result-এ শুধু নাম ও তারিখ নয়, rule trace থাকা উচিত:

• festivalId ও displayed observance name;
• ruleProfileId, school/tradition ও source note;
• candidate local dates;
• sunrise, sunset, next sunrise ও rule interval;
• তিথি/নক্ষত্রের start ও end instants;
• overlap seconds, coverage ratio ও applied predicate;
• tie-break rule এবং selected candidate;
• engine, ephemeris ও time-zone-data version।

উদাহরণস্বরূপ user-facing ব্যাখ্যা:

“এই দিনের প্রদোষ interval ১৭:২৮–১৯:৫৩। ত্রয়োদশী ১৮:১০ থেকে interval-এর ১০৩ মিনিট ব্যাপ্ত ছিল; পরের দিনের overlap ৪১ মিনিট। MaxOverlap ও profile tie-break অনুসারে প্রথম দিন নির্বাচিত।”

এমন trace printed Panjika-এর সঙ্গে mismatch গবেষণায় অমূল্য। Result আলাদা হলে প্রথমে গ্রহগণনা নয়—sunrise profile, interval definition, tithi boundary এবং tradition policy তুলনা করা যায়।

DST, high latitude ও boundary cases

• DST: Fraction ও duration UTC instant-এ গণনা করুন; শেষে local time-এ format করুন।
• Next sunrise: বর্তমান sunrise + ২৪ ঘণ্টা নয়; পরের local date-এর sunrise পুনর্গণিত হবে।
• Exact boundary: Half-open [start, end) ব্যবহার করুন।
• No rise/no set: Polar day/night-এ interval বানাবেন না; documented fallback profile না থাকলে status ফেরান।
• Ambiguous local time: Local string থেকে instant reconstruct না করে original DateTimeOffset রাখুন।
• Skipped local time: Time-zone transition day-এ wall-clock subtraction এড়িয়ে UTC arithmetic করুন।
• Very small overlap: Tradition যদি “স্পর্শমাত্র” গ্রহণ করে AnyOverlap; software নিজে arbitrary ১-মিনিট tolerance যোগ করবে না।
• Numerical tolerance: Root solver-এর precision tolerance ও religious rule tolerance আলাদা রাখুন এবং trace-এ প্রকাশ করুন।

API ও XML-এ rule interval প্রকাশ

{
  "festival": "janmashtami",
  "localDate": "2026-09-04",
  "ruleProfileId": "janmashtami-local-nishitha-v1",
  "solarProfileId": "sun-center-no-refraction-v1",
  "ruleInterval": {
    "id": "nishitha-night-eighth-muhurta-v1",
    "start": "...ISO local time...",
    "end": "...ISO local time...",
    "midpoint": "...ISO local time..."
  },
  "tests": [
    {
      "state": "krishna-ashtami",
      "requirement": "AnyOverlap",
      "overlapSeconds": 0,
      "passed": false
    }
  ],
  "selected": false
}

উপরের values schema বোঝানোর জন্য illustrative। XML:

<festival-rule-trace festival="pradosha-vrata"
    profile="dharmasindhu-3-night-muhurta-v1"
    selected-date="...">
  <solar-day profile="sun-center-no-refraction-v1">
    <sunset>...</sunset>
    <next-sunrise>...</next-sunrise>
  </solar-day>
  <rule-interval start="..." end="..." end-exclusive="true" />
  <tithi name="trayodashi" start="..." end="..." />
  <evaluation requirement="MaxOverlap"
      overlap-seconds="..." coverage="..." passed="true" />
</festival-rule-trace>

Public API-তে compact result দিতে পারেন, কিন্তু research/debug mode-এ পূর্ণ trace রাখুন। Cache key-তে location, time zone, solar profile, festival rule profile এবং engine version অন্তর্ভুক্ত করুন।

Validation checklist

1. Sunrise, sunset ও next sunrise একই solar profile থেকে এসেছে;
2. Next sunrise পরের local date থেকে solve করা হয়েছে;
3. Aruṇodaya exactly ৯৬ absolute minutes before sunrise;
4. Aruṇodaya-কে twilight angle ধরে গণনা করা হয়নি;
5. Daylight পাঁচ সমান proportional ভাগে বিভক্ত;
6. Madhyahna fraction ঠিক [২/৫, ৩/৫);
7. Night ১৫ proportional মুহূর্তে বিভক্ত;
8. Nishitha fraction ঠিক [৭/১৫, ৮/১৫);
9. Nishitha midpoint sunset ও next sunrise-এর midpoint;
10. Civil 12:00 AM-কে Nishitha hard-code করা নেই;
11. PradoshaPolicy ID ও authority সংরক্ষিত;
12. একাধিক Pradosha convention একই constant-এ মিশে যায়নি;
13. সব interval half-open [start, end);
14. Exact end boundary double-count হয় না;
15. AnyOverlap, AtMidpoint ও FullCoverage পৃথক test;
16. Overlap zero হলে coverage zero;
17. Candidate-day overlap durations trace-এ আছে;
18. Tie-break deterministic ও documented;
19. Tithi/nakṣatra raw instants string formatting-এর আগে সংরক্ষিত;
20. DST spring-forward day test করা হয়েছে;
21. DST fall-back day test করা হয়েছে;
22. Dhaka, Kolkata ও New York regression cases আছে;
23. Short winter day ও long summer day test আছে;
24. No-rise/no-set condition fabricated time দেয় না;
25. Festival rule profile cache key-তে আছে;
26. Printed Panjika comparison-এ applied rule code দেখা যায়;
27. API, HTML, print ও XML একই selected result ব্যবহার করে।

উপসংহার

উৎসবের তারিখ astronomical timeline ও ধর্মীয় rule—দুই স্তরের ফল। সূর্যোদয়-তিথি daily header-এর জন্য গুরুত্বপূর্ণ, কিন্তু সব observance-এর জন্য যথেষ্ট নয়। অরুণোদয় একটি fixed ৯৬-minute instant; মধ্যাহ্ন actual daylight-এর তৃতীয় পঞ্চমাংশ; নিশীথ local night-এর অষ্টম মুহূর্ত; আর প্রদোষের operational definition tradition-specific policy হিসেবে রাখা উচিত।

Engine যদি raw তিথি-নক্ষত্র intervals-এর সঙ্গে rule interval-এর overlap মাপে, তবে AnyOverlap, AtMidpoint, FullCoverage বা MaxOverlap স্পষ্টভাবে প্রয়োগ করা যায়। এতে result শুধু “তারিখ” নয়—কোন মুহূর্ত, কতক্ষণ ব্যাপ্তি এবং কোন rule-এর কারণে সেই তারিখ নির্বাচিত হলো তার audit trail-সহ প্রকাশিত হয়।

এই পদ্ধতি historical printed Panjika যাচাই, বহু-location calculation এবং ভবিষ্যৎ Assamese বা অন্য ভাষার display—সবক্ষেত্রেই একই calculation core ব্যবহার করতে দেয়। ভাষা বদলাবে renderer-এ; rule profile বদলাবে tradition selection-এ; কিন্তু astronomical instants অপরিবর্তিত থাকবে।

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

1. SriPedia—Sandhyāvandanam; sunrise-to-sunset day-এর পাঁচ ভাগ—প্রাতঃ, সঙ্গব, মধ্যাহ্ন, অপরাহ্ণ ও সায়াহ্ন।
2. Shastra Panchangam—Pradosham; Dharmasindhu-ভিত্তিক তিন মুহূর্ত-পরবর্তী-sunset interval ও ত্রয়োদশী-ব্যাপ্তির selection rule।
3. KaalPanchang—Nishita Kala; local sunset ও next sunrise-এর মধ্যে রাত্রির মধ্যবর্তী মুহূর্ত।
4. PanchangTime—How Ekadashi Is Dated; sunrise, ৯৬-minute aruṇodaya, Dashami-viddha ও pāraṇa rule-এর explanatory treatment।
5. Hindupedia—Pradoṣa; ছয় ঘটিকা এবং কিছু authority-তে তিন ঘটিকার ভিন্ন convention-এর উল্লেখ।
6. সূর্য সিদ্ধান্ত পঞ্জিকা project specification; Sun center/no-refraction solar profile, UTC interval arithmetic, C# 5 compatibility এবং versioned observance policies.