সূর্য সিদ্ধান্ত পঞ্জিকা সকল প্রবন্ধ

তিথি, নক্ষত্র, করণ ও যোগ: শেষ সময় থেকে পরবর্তী অঙ্গ নির্ণয়

সূর্য-চন্দ্রের নিরয়ণ দ্রাঘিমা থেকে তিথি, নক্ষত্র, করণ ও যোগ নির্ণয়, তাদের শেষ মুহূর্ত খোঁজা, ‘পর্যন্ত পরে’ আউটপুট এবং C# transition solver-এর পূর্ণ ব্যাখ্যা।

তিথি, নক্ষত্র, করণ ও যোগ কোনো civil-date label নয়। এগুলো সূর্য ও চন্দ্রের চলমান দ্রাঘিমা থেকে নির্ণীত angular segment। Clock time কেবল সেই segment-এর পরবর্তী boundary-তে পৌঁছানোর স্থানীয় সময়। তাই একটি নির্ভরযোগ্য পঞ্জিকা engine প্রথমে angle ও state নির্ণয় করবে, তারপর boundary instant খুঁজবে, এবং সবশেষে selected timezone ও ভাষায় ফল দেখাবে।

পঞ্জিকার “শেষ সময়” বলতে কী বোঝায়?

রাষ্ট্রীয় পঞ্জিকাসহ প্রচলিত almanac-এ তিথি, নক্ষত্র, যোগ বা করণের পাশে যে সময় লেখা হয়, তা সাধারণত ঐ অঙ্গটির ending moment। উদাহরণ:

এখানে sunrise-এ ত্রয়োদশী চলছিল। রাত ১০:১৪:৫০-এ সূর্য থেকে চন্দ্রের angular separation পরবর্তী ১২°-এর গুণিতকে পৌঁছেছে। সেই instant-এর আগে ত্রয়োদশী, boundary instant থেকে চতুর্দশী। “পর্যন্ত” শব্দটি display convention; machine model-এ ownership স্পষ্ট করতে transition instant এবং from/to state আলাদা field-এ রাখা উচিত।

চার অঙ্গের angular ভিত্তি

নিচের সব angle ০° থেকে ৩৬০°-এর মধ্যে normalize করা হয়েছে। λS হলো সূর্যের দ্রাঘিমা এবং λM চন্দ্রের দ্রাঘিমা। Project profile অনুযায়ী এগুলো traditional Surya Siddhanta অথবা modern ephemeris-ভিত্তিক হতে পারে; কিন্তু একই report-এর চার অঙ্গে একই declared coordinate profile ব্যবহার করতে হবে।

অঙ্গ মূল angle এক অংশ মোট অংশ
তিথিNormalize(λM − λS)১২°৩০
নক্ষত্রNormalize(λM)১৩°২০′২৭
করণNormalize(λM − λS)৬°৬০ half-tithi slot
যোগNormalize(λM + λS)১৩°২০′২৭

১৩°২০′-কে decimal-এ 360.0 / 27.0 হিসেবেই রাখুন; rounded 13.33 ব্যবহার করলে প্রতি boundary-তে error জমবে। Name array zero-based হলেও user-facing ordinal এক-based।

তিথি: সূর্য থেকে চন্দ্রের প্রতি ১২° দূরত্ব

অমাবস্যার মুহূর্তে সূর্য ও চন্দ্রের দ্রাঘিমা সমান; elongation ০°। চন্দ্র সূর্যের চেয়ে এগিয়ে ১২° হলে শুক্ল প্রতিপদ শেষ এবং দ্বিতীয়া শুরু। ৩৬০° synodic cycle-এ ৩০টি তিথি:

Elongationতিথিপরের boundary
০° ≤ E < ১২°শুক্ল প্রতিপদ১২°
১২° ≤ E < ২৪°শুক্ল দ্বিতীয়া২৪°
১৫৬° ≤ E < ১৬৮°শুক্ল চতুর্দশী১৬৮°—পূর্ণিমার শুরু
১৬৮° ≤ E < ১৮০°পূর্ণিমা১৮০°—কৃষ্ণপক্ষের শুরু
১৮০° ≤ E < ১৯২°কৃষ্ণ প্রতিপদ১৯২°
৩৪৮° ≤ E < ৩৬০°অমাবস্যা০°/৩৬০°—নতুন cycle

পূর্ণিমা নামটি ১৮০°-এ শেষ হওয়া bright-fortnight tithi এবং অমাবস্যা ৩৬০°-এ শেষ হওয়া dark-fortnight tithi। Index mapping লিখতে array-এর ১৪ নম্বর slot-এ পূর্ণিমা, ২৯ নম্বর slot-এ অমাবস্যা রাখুন। শুধু (index % 15) + 1 দেখালে পক্ষ জানা গেলেও পূর্ণিমা/অমাবস্যার বিশেষ নাম হারিয়ে যেতে পারে।

নক্ষত্র: চন্দ্রের নিরয়ণ দ্রাঘিমার ২৭ ভাগ

Ecliptic-কে ২৭টি সমান ভাগ করলে প্রতিটি ভাগ ১৩°২০′। অশ্বিনী ০° থেকে শুরু ধরে:

নক্ষত্রে সূর্যের angle লাগে না; লাগে চন্দ্রের declared sidereal longitude। তাই ayanāṃśa/profile বদলালে nakshatra boundary বদলাতে পারে। Traditional engine যদি নিজস্ব nirayana frame দেয়, তার value-কে আবার Lahiri ayanāṃśa দিয়ে subtract করবেন না। Modern Swiss Ephemeris profile-এ যে sidereal mode ঘোষণা করা হয়েছে সেটিই consistently ব্যবহার করুন।

Indexনক্ষত্রSidereal span
০অশ্বিনী০°০০′–১৩°২০′
১ভরণী১৩°২০′–২৬°৪০′
২কৃত্তিকা২৬°৪০′–৪০°০০′
২৬রেবতী৩৪৬°৪০′–৩৬০°০০′

Abhijit-কে ritual interval হিসেবে কোনো বিশেষ rule-এ ব্যবহার করা হলেও সাধারণ ২৭-nakshatra Panchanga indexing-এর মাঝখানে ২৮তম equal segment ঢোকাবেন না। এমন rule থাকলে base 27-segment timeline-এর ওপর আলাদা derived interval হিসেবে রাখুন।

করণ: অর্ধতিথি, কিন্তু নামের ক্রম বিশেষ

এক করণ ৬° elongation, অর্থাৎ এক তিথির অর্ধাংশ। ৩৬০°-এ ৬০টি karana slot হলেও নাম ১১টি। চারটি স্থির এবং সাতটি চল করণ পুনরাবৃত্ত হয়।

Slotকরণের নিয়মনাম
০প্রথম স্থির করণকিংস্তুঘ্ন
১–৫৬সাতটি নাম আটবার cycleবব, বালব, কৌলব, তৈতিল, গর, বণিজ, বিষ্টি
৫৭শেষের স্থির করণশকুনি
৫৮শেষের স্থির করণচতুষ্পাদ
৫৯শেষের স্থির করণনাগ

Common bug হলো halfIndex % 7 দিয়ে সব ৬০ slot map করা। এতে কিংস্তুঘ্ন এবং শেষ তিন স্থির করণ ভুল হয়। সঠিক mapping:

static readonly string[] MovableKarana =
{
    "বব", "বালব", "কৌলব", "তৈতিল", "গর", "বণিজ", "বিষ্টি"
};

static string KaranaName(int halfIndex)
{
    if (halfIndex == 0) return "কিংস্তুঘ্ন";
    if (halfIndex >= 1 && halfIndex <= 56)
        return MovableKarana[(halfIndex - 1) % 7];
    if (halfIndex == 57) return "শকুনি";
    if (halfIndex == 58) return "চতুষ্পাদ";
    if (halfIndex == 59) return "নাগ";
    throw new ArgumentOutOfRangeException("halfIndex");
}

যোগ: সূর্য ও চন্দ্রের দ্রাঘিমার যোগফল

যোগ নির্ণয়ে subtraction নয়, normalized sum ব্যবহৃত হয়। ৩৬০°-কে ২৭ ভাগ করে প্রতিটি segment ১৩°২০′:

প্রথম segment বিষ্কম্ভ, তারপর প্রীতি, আয়ুষ্মান ইত্যাদি; ২৭তম বৈধৃতি। সূর্য ও চন্দ্রের longitude একই frame-এ হতে হবে। একটি tropical এবং অন্যটি sidereal হলে নাম ও boundary দুটোই অর্থহীন হয়ে যাবে।

যোগ phase দিনে চন্দ্রের motion-এর সঙ্গে সূর্যের motion-ও যোগ করে এগোয়। তাই nakshatra ও yoga উভয়ের segment width ১৩°২০′ হলেও ending time এক নয়। শুধু চন্দ্রের nakshatra end কপি করে yoga end বানানো যাবে না।

Current অঙ্গের শেষ থেকে next অঙ্গ

কোনো instant-এ phase P এবং segment width W হলে current index ও remaining angle:

শেষ segment-এ nextBoundary = 360°; root-এর পরে phase ০°-এ wrap করে index ০ হয়। Current এবং next name array থেকে পাওয়া যায়:

int currentIndex = StateIndex(phase, width, count);
int nextIndex = (currentIndex + 1) % count;

string text = names[currentIndex]
    + " " + FormatEndingTime(boundaryLocal)
    + " পর্যন্ত পরে " + names[nextIndex];

Boundary instant-এ evaluation করলে নতুন state পাওয়া উচিত। তবে floating-point rounding-এ exact angle boundary-এর সামান্য নিচে দেখা যেতে পারে। তাই stored transition-এ solver-এর intended NextIndex রাখুন; display করার সময় boundary instant আবার divide করে name অনুমান করবেন না।

তিথি বা নক্ষত্রের সময়কাল সমান নয় কেন?

প্রতিটি segment-এর angular width সমান, কিন্তু সূর্য ও চন্দ্রের apparent motion সমান গতির নয়। বিশেষত চন্দ্রের orbital speed ক্রমাগত বদলায়। ফলে:

  • এক তিথি fixed ২৪ ঘণ্টা নয়;
  • এক নক্ষত্র fixed এক civil day নয়;
  • দুই করণের সময়কাল একই নাও হতে পারে;
  • নক্ষত্র ও যোগের width সমান হলেও তাদের phase speed আলাদা;
  • এক Panchanga day-এ কোনো অঙ্গ না-ও বদলাতে পারে, আবার একাধিকবার বদলাতে পারে।

Average duration দিয়ে ending time বানানো তাই গ্রহণযোগ্য নয়। Average কেবল initial search estimate দিতে পারে; final instant অবশ্যই engine-এর actual longitude function-এর root থেকে আসবে।

৩৬০° wrap-এর নিরাপদ গণনা

সরাসরি moonLongitude - sunLongitude ব্যবহার করলে ৩৫৯° থেকে ০° crossing-এ negative value বা ৩৬০° jump দেখা যায়। সব phase normalize করুন:

static double NormalizeDegrees(double value)
{
    value %= 360.0;
    if (value < 0.0) value += 360.0;
    return value;
}

static double ForwardDegrees(double from, double to)
{
    return NormalizeDegrees(to - from);
}

Index calculation-এর আগে খুব ছোট numerical overflow সামলান। কোনো engine ৩৬০.০০০০০০০০০১ দিলে normalize করে ০ করতে হবে; আবার ৩৫৯.৯৯৯৯৯৯৯৯-কে অযথা ০ করবেন না। একটি documented angular tolerance ব্যবহার করুন এবং raw angle diagnostics-এ রাখুন।

Ending moment: bracket, তারপর refine

Reliable boundary solver-এর দুই ধাপ:

  1. Bracket: বর্তমান instant থেকে ছোট step-এ এগিয়ে target angular advance অতিক্রম করা পর্যন্ত search;
  2. Refine: bracket-এর মধ্যে bisection বা Brent method দিয়ে প্রয়োজনীয় time tolerance পর্যন্ত root সংকুচিত করা।

তিথি, নক্ষত্র, করণ ও যোগের phase সাধারণ daily interval-এ forward চলে; তবু solver-কে search horizon, iteration guard ও failure diagnostic দিতে হবে। Silent fallback হিসেবে “২৪ ঘণ্টা পরে” দেখানো বিপজ্জনক।

Parameterব্যবহারিক সূচনামন্তব্য
Bracket step৩০–৬০ মিনিট৬° করণ boundary-ও নিরাপদে ধরা যায়
Search horizonতিথি/নক্ষত্র/যোগ ৩ দিন; করণ ২ দিনFailure হলে engine/profile inspect করুন
Time tolerance০.২৫–১ secondDisplay precision-এর চেয়ে সূক্ষ্ম রাখুন
Stored precisionJulian Day UT + UTC instantRounded display থেকে পুনর্গণনা নয়

এক সূর্যোদয় থেকে পরের সূর্যোদয়: সব পরিবর্তন রাখুন

Sunrise-এ current state ও তার প্রথম ending time জানলেই daily report সম্পূর্ণ নাও হতে পারে। বিশেষ করে করণ প্রায়ই একই Panchanga day-এ দুবার বদলায়; ক্ষয় তিথির ক্ষেত্রে তিথিও একাধিক boundary অতিক্রম করতে পারে। তাই:

  1. Sunrise instant-এ current state নিন;
  2. তার next boundary solve করুন;
  3. Boundary next sunrise-এর আগে হলে event যোগ করুন;
  4. Next state থেকে আবার boundary খুঁজুন;
  5. Next sunrise বা guard limit-এ পৌঁছালে থামুন।

Boundary next sunrise-এর exact instant হলে বর্তমান daily record-এ নয়, next record-এ যাবে। আগের নিবন্ধে ব্যবহৃত half-open interval এই duplication বন্ধ করে। কোনো boundary না থাকলে তিথির project label “অহোরাত্র” হতে পারে; অন্য অঙ্গেও structured response-এ endsWithinWindow: false রাখা যায়।

C# 5/.NET Framework-compatible implementation

নিচের model-এ কোনো modern record, tuple বা init property নেই; তাই পুরোনো Web Forms/Desktop project-এ সহজে নেওয়া যায়:

public sealed class PanchangaAngles
{
    public double SunLongitude { get; set; }
    public double MoonLongitude { get; set; }
}

public sealed class AngaTransition
{
    public string Anga { get; set; }
    public int FromIndex { get; set; }
    public int ToIndex { get; set; }
    public string FromName { get; set; }
    public string ToName { get; set; }
    public double JulianDayUt { get; set; }
    public DateTimeOffset LocalTime { get; set; }
}

public sealed class AngaDefinition
{
    public string Name { get; set; }
    public int Count { get; set; }
    public double SegmentDegrees { get; set; }
    public Func<PanchangaAngles, double> Phase { get; set; }
    public Func<int, string> StateName { get; set; }
}

চার অঙ্গের definition:

AngaDefinition tithi = new AngaDefinition
{
    Name = "তিথি",
    Count = 30,
    SegmentDegrees = 12.0,
    Phase = a => NormalizeDegrees(a.MoonLongitude - a.SunLongitude),
    StateName = i => TithiNames[i]
};

AngaDefinition nakshatra = new AngaDefinition
{
    Name = "নক্ষত্র",
    Count = 27,
    SegmentDegrees = 360.0 / 27.0,
    Phase = a => NormalizeDegrees(a.MoonLongitude),
    StateName = i => NakshatraNames[i]
};

AngaDefinition karana = new AngaDefinition
{
    Name = "করণ",
    Count = 60,
    SegmentDegrees = 6.0,
    Phase = a => NormalizeDegrees(a.MoonLongitude - a.SunLongitude),
    StateName = KaranaName
};

AngaDefinition yoga = new AngaDefinition
{
    Name = "যোগ",
    Count = 27,
    SegmentDegrees = 360.0 / 27.0,
    Phase = a => NormalizeDegrees(a.MoonLongitude + a.SunLongitude),
    StateName = i => YogaNames[i]
};

একটি compact bracket-and-bisection solver:

double FindNextBoundary(
    double startJdUt,
    AngaDefinition anga,
    Func<double, PanchangaAngles> positions,
    double stepDays,
    double maxDays)
{
    double phase0 = anga.Phase(positions(startJdUt));
    double inside = phase0 % anga.SegmentDegrees;
    double needed = anga.SegmentDegrees - inside;

    // At an exact boundary, seek the end of the newly-started segment.
    if (needed < 1e-10) needed = anga.SegmentDegrees;

    Func<double, double> f = delegate(double jd)
    {
        double phase = anga.Phase(positions(jd));
        return ForwardDegrees(phase0, phase) - needed;
    };

    double left = startJdUt;
    double right = left + stepDays;
    double limit = startJdUt + maxDays;

    while (right <= limit && f(right) < 0.0)
    {
        left = right;
        right += stepDays;
    }

    if (right > limit)
        throw new InvalidOperationException(
            anga.Name + "-এর পরবর্তী boundary পাওয়া যায়নি।");

    for (int i = 0; i < 60; i++)
    {
        double mid = (left + right) * 0.5;
        if (f(mid) < 0.0) left = mid;
        else right = mid;
    }

    return (left + right) * 0.5;
}

stepDays = 1.0 / 24.0 অর্থ এক ঘণ্টা। Production code-এ engine call cache, ephemeris error propagation এবং cancellation support যোগ করুন। Search interval দুই দিনের কম হওয়ায় ForwardDegrees এক পূর্ণ cycle wrap করার ঝুঁকি নেই; generic long-range solver-এ continuous unwrapped phase ব্যবহার করুন।

Daily scanner:

List<AngaTransition> ScanAnga(
    DateTimeOffset sunrise,
    DateTimeOffset nextSunrise,
    AngaDefinition anga,
    Func<double, PanchangaAngles> positions)
{
    var result = new List<AngaTransition>();
    double cursor = ToJulianDayUt(sunrise);
    double end = ToJulianDayUt(nextSunrise);

    for (int guard = 0; guard < 8; guard++)
    {
        double phase = anga.Phase(positions(cursor));
        int from = (int)Math.Floor(phase / anga.SegmentDegrees);
        if (from >= anga.Count) from = 0;

        double boundary = FindNextBoundary(
            cursor, anga, positions, 1.0 / 24.0, 3.0);

        if (boundary >= end) break;

        int to = (from + 1) % anga.Count;
        result.Add(new AngaTransition
        {
            Anga = anga.Name,
            FromIndex = from,
            ToIndex = to,
            FromName = anga.StateName(from),
            ToName = anga.StateName(to),
            JulianDayUt = boundary,
            LocalTime = FromJulianDayUt(boundary)
        });

        cursor = boundary + (0.5 / 86400.0); // half-second progress
    }

    return result;
}

শেষ line-এর half-second progress solver-এর tolerance-এর চেয়ে বড় এবং display precision-এর তুলনায় ছোট। আরও পরিষ্কার architecture-এ FindNextBoundary-কে expected next state দিন, যাতে artificial time shift-এর দরকার না হয়। Guard শেষ হলে silent partial result নয়—diagnostic throw করুন।

বাংলা clock time, নিশা এবং দণ্ড-পল-বিপল

Astronomical instant একবার নির্ণীত হলে presentation layer একাধিক রূপ দিতে পারে:

রূপউদাহরণভিত্তি
Local clockরাত্র ঘ ১০:১৪:৫০Selected timezone
Post-midnightনিশা ঘ ২:৫৯:১২Same sunrise-window, next civil date
দণ্ড-পল-বিপলদং ৪০/৪৬/১৬.৬২Sunrise থেকে elapsed traditional time
ISO/API2026-10-09T02:59:12+05:30Date, time ও offset

এক solar day-কে conventionally ৬০ দণ্ড, এক দণ্ডকে ৬০ পল এবং এক পলকে ৬০ বিপল ধরা হয়। Modern fixed conversion-এ ১ দণ্ড = ২৪ মিনিট, ১ পল = ২৪ second, ১ বিপল = ০.৪ second। Project-এর printed format sunrise-relative হলে:

double elapsedSeconds = (eventLocal - sunriseLocal).TotalSeconds;
double totalDanda = elapsedSeconds / (24.0 * 60.0);

int danda = (int)Math.Floor(totalDanda);
double totalPala = (totalDanda - danda) * 60.0;
int pala = (int)Math.Floor(totalPala);
double bipala = (totalPala - pala) * 60.0;

Clock string থেকে দণ্ড হিসাব করবেন না; actual instants subtract করুন। DST transition, historical offset বা midnight crossing-এ string arithmetic ভুল ফল দেয়। কোন convention—fixed ২৪-minute daṇḍa, নাকি actual sunrise-to-next-sunrise-কে ৬০ ভাগ—ব্যবহার করছেন তা metadata-তে ঘোষণা করুন; দুই পদ্ধতি মেশাবেন না।

Traditional Surya Siddhanta ও Drik ফল আলাদা রাখুন

এই boundary algorithm উভয় profile-এ ব্যবহার করা যায়, কিন্তু position provider আলাদা:

Profileসূর্য/চন্দ্র longitudeExpected use
Traditional Surya SiddhantaTraditional mean/true corrections ও declared bījaঐতিহ্যিক printed Panjika fit
Drik/LahiriModern ephemeris + declared sidereal modeObservational/modern astronomical profile

Saṅkrānti ও Bengali-date matching-এর জন্য project-এর আলাদা modern-fit star correction থাকলেও তা তিথি, নক্ষত্র, করণ, যোগ বা planetary positions-এ অনিচ্ছাকৃতভাবে প্রয়োগ করা যাবে না। প্রতিটি result-এ calculationProfileId, bīja status, ayanāṃśa এবং ephemeris version রাখলে ভিন্ন পদ্ধতির ফল গুলিয়ে যায় না।

Validation checklist

  1. Angle normalize সবসময় ০° ≤ value < ৩৬০°;
  2. ৩৫৯.৯৯° থেকে ০.০১° crossing forward হিসেবে ধরা হয়;
  3. তিথি প্রতি ১২°, করণ প্রতি ৬°;
  4. নক্ষত্র ও যোগের width exact 360/27;
  5. শুক্ল/কৃষ্ণ পক্ষ index ০–২৯ সঠিক;
  6. পূর্ণিমা ও অমাবস্যার বিশেষ নাম ঠিক;
  7. করণ slot ০ কিংস্তুঘ্ন;
  8. করণ slot ১–৫৬ সাত নামের cycle;
  9. করণ slot ৫৭–৫৯ শকুনি, চতুষ্পাদ, নাগ;
  10. রেবতী → অশ্বিনী wrap;
  11. বৈধৃতি → বিষ্কম্ভ wrap;
  12. অমাবস্যা → শুক্ল প্রতিপদ wrap;
  13. Exact boundary instant নতুন state-এর;
  14. Root-এর এক second আগে পুরোনো state;
  15. Root-এর এক second পরে নতুন state;
  16. এক day-এ দুই করণ transition হারায় না;
  17. ক্ষয় তিথির একাধিক transition হারায় না;
  18. Next sunrise exact boundary next record-এর;
  19. Post-midnight event “নিশা” এবং full ISO date পায়;
  20. No-boundary tithi project rule অনুযায়ী “অহোরাত্র”;
  21. Dhaka, Kolkata ও New York-এ একই UTC root-এর local time ঠিক;
  22. DST day-এ fixed ২৪-hour assumption নেই;
  23. Traditional ও Drik result পৃথক cache key ব্যবহার করে;
  24. Displayed next name stored ToIndex থেকে আসে;
  25. Solver failure diagnostic-এ anga, JD, angles ও profile আছে;
  26. Daily HTML, API ও XML একই transition IDs ব্যবহার করে।

উপসংহার

তিথি, নক্ষত্র, করণ ও যোগের পাশে লেখা সময় কোনো আনুমানিক দৈর্ঘ্য নয়; এটি একটি নির্দিষ্ট angular boundary অতিক্রমের মুহূর্ত। তিথি ও করণ সূর্য–চন্দ্রের elongation, নক্ষত্র চন্দ্রের sidereal longitude, আর যোগ সূর্য ও চন্দ্রের longitude sum থেকে আসে। তাই calculation pipeline হওয়া উচিত: position → normalized phase → current segment → next boundary root → local display।

“পর্যন্ত পরে…” output তৈরি করতে current name, ending instant এবং stored next name তিনটিই দরকার। Circular angle wrap, exact boundary ownership এবং numerical tolerance স্পষ্ট না হলে বিশেষত অমাবস্যা, রেবতী বা বৈধৃতি crossing-এ off-by-one error হবে। করণের স্থির ও চল নামের ক্রমও আলাদা করে map করতে হবে।

সবচেয়ে গুরুত্বপূর্ণ হলো প্রথম transition-এ থেমে না যাওয়া। Current sunrise inclusive থেকে next sunrise exclusive পর্যন্ত প্রতিটি boundary scan করলে ক্ষয় তিথি, একাধিক করণ এবং নিশার event হারায় না। একই structured timeline থেকে Daily Details, print report, API ও yearly XML render করলে চার জায়গায় চার রকম ফল হওয়ার ঝুঁকিও দূর হয়।

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

  1. Positional Astronomy Centre, Kolkata—Rashtriya Panchang explanation; তিথি, নক্ষত্র, যোগ ও করণের পাশে প্রদত্ত সময় ending moment।
  2. Positional Astronomy Centre—Names of Tithis, Nakshatras, Yogas, Karanas and Rasis.
  3. Robert Sewell ও Śaṅkara Bālakṛṣṇa Dīkṣita—The Indian Calendar, 1896; তিথি ১২°, নক্ষত্র ও যোগ ১৩°২০′, করণ ৬°-এর সংজ্ঞা।
  4. M. Yano ও M. Fushimi—Pancanga 3.14 program notes; traditional calculation context.
  5. Astrodienst—Swiss Ephemeris Programmer’s Documentation; longitude, Julian Day, time scale ও ephemeris flags.
  6. Government of India—Report of the Calendar Reform Committee, 1955.
  7. সূর্য সিদ্ধান্ত পঞ্জিকা project; Traditional Fit, Drik profile, daily sunrise-window, API এবং XML output conventions.

মন্তব্য, আলোচনা ও প্রশ্ন