ঐতিহাসিক পঞ্জিকা গবেষণা: উৎস, অনিশ্চয়তা ও পুনরুৎপাদনযোগ্যতা

ঐতিহাসিক পঞ্জিকা যাচাইয়ের সবচেয়ে বড় প্রশ্ন “কোন ফলটি ঠিক?” নয়; বরং “এই ফলটি কোন উৎস, কোন calendar convention, কোন location, কোন algorithm এবং কোন software version থেকে এসেছে?” একই astronomical instant-কে Julian ও Gregorian calendar-এ আলাদা তারিখে লেখা যায়। একই civil date-এ ভিন্ন স্থানের sunrise আলাদা। আবার একই traditional text-এর একাধিক regional implementation থাকতে পারে। তাই ফলের সঙ্গে তার উৎপত্তির পূর্ণ ইতিহাস সংরক্ষণই গবেষণার মূল ভিত্তি।

পুনরুৎপাদনযোগ্যতা বলতে কী বোঝায়?

এই project-এ একটি calculation পুনরুৎপাদনযোগ্য তখনই, যখন অন্য ব্যক্তি ঘোষিত source data, input, configuration, code version ও dependency version ব্যবহার করে একই raw result—নির্ধারিত tolerance-এর মধ্যে—আবার তৈরি করতে পারেন।

পুনরুৎপাদনযোগ্য ফল modern observation-এর সঙ্গে অবশ্যই মিলে যাবে—এমন নয়। একটি historical Surya Siddhanta model নিজের ঘোষিত constants ও rules অনুযায়ী সম্পূর্ণ reproducible হতে পারে, যদিও modern ephemeris-এর সঙ্গে তার longitude difference থাকে। অন্যদিকে একটি visually convincing calendar reproducible নাও হতে পারে, যদি ব্যবহৃত correction বা timezone অজানা থাকে।

উৎস, পাঠ ও গণনার তিনটি আলাদা স্তর

একটি scanned Panjika page দেখেই value সরাসরি database-এর “সত্য” field-এ বসানো উচিত নয়। অন্তত তিনটি স্তর আলাদা রাখুন:

1. Source layer: scan, বই, পাণ্ডুলিপি, edition, page ও ownership;
2. Transcription layer: source-এ যা মুদ্রিত বা লিখিত আছে তার faithful reading;
3. Interpretation/calculation layer: modern unit conversion, calendar conversion, rule identification ও engine result।

এভাবে source-এ ভুল থাকলেও source record পরিবর্তিত হয় না। Researcher আলাদা annotation-এ বলতে পারেন: “মুদ্রিত value সম্ভবত ৩১ নয়, ৩৭” অথবা “এই date Julian label”; ভবিষ্যতের reviewer মূল image দেখে সিদ্ধান্ত যাচাই করতে পারবেন।

প্রতিটি source record-এ কী থাকবে?

একটি বইয়ের নাম লিখলেই citation সম্পূর্ণ হয় না। Historical Panjika প্রায়ই ভিন্ন printing, edition, location ও compiler অনুযায়ী বদলে যায়। ন্যূনতম metadata:

একই page-এর crop, contrast-enhanced image ও OCR output থাকলে original scan-কে authoritative source রাখুন। Derived image-এর সঙ্গে transformation note দিন—যেমন crop coordinates, deskew angle বা contrast setting।

মূল পাঠ পরিবর্তন করবেন না

Diplomatic transcription-এ source-এ যা আছে তাই রাখা হয়—পুরোনো বানান, punctuation, abbreviation এবং সম্ভাব্য মুদ্রণভুলসহ। এরপর normalized transcription-এ search বা calculation-এর সুবিধার জন্য standard spelling ও units দেওয়া যায়।

যেমন একটি ক্ষতিগ্রস্ত অঙ্ক “৩১” বা “৩৭”—দুইভাবেই পড়া সম্ভব হলে source_text-এ একটি guess বসিয়ে অন্যটি হারিয়ে ফেলবেন না। দুটি candidate reading, প্রত্যেকটির confidence এবং reviewer note রাখুন।

Julian, Gregorian ও dual-date policy

“২০ মার্চ ৫৯৪” লিখলে প্রশ্ন থাকে—এটি Julian, proleptic Gregorian, নাকি modern software-এর default Gregorian label? Calendar system না লিখলে historical date অসম্পূর্ণ।

Gregorian reform তাৎক্ষণিকভাবে পৃথিবীর সব অঞ্চলে কার্যকর হয়নি। ১৫৮২ সালে প্রথম গ্রহণকারী অঞ্চলে ৪ অক্টোবরের পর ১৫ অক্টোবর এসেছিল—৫ থেকে ১৪ অক্টোবর পর্যন্ত দশটি civil-date label বাদ যায়। Britain ও তার dominions-এ ১৭৫২ সালে ২ সেপ্টেম্বরের পর ১৪ সেপ্টেম্বর আসে—৩ থেকে ১৩ সেপ্টেম্বর পর্যন্ত এগারোটি label বাদ যায়। অন্য অঞ্চল অন্য সময়ে পরিবর্তন করেছে।

Historical Bengali calendar export-এর জন্য এই project-এর নীতি:

1. Calculation-এর canonical identity হবে continuous Julian Day বা equivalent instant;
2. Early year-এ একই instant-এর Julian ও proleptic Gregorian label পাশাপাশি দেখানো হবে;
3. কোনোটিকে নীরবে “আসল” ও অন্যটিকে “ভুল” বলা হবে না;
4. Historical civil-use claim করলে সংশ্লিষ্ট অঞ্চল ও adoption rule cite করতে হবে;
5. Weekday instant-এর সঙ্গে যুক্ত থাকবে; calendar label বদলালেও weekday ইচ্ছামতো বদলাবে না;
6. Batch filename-এর internal key calendar label নয়—Bengali year বা stable record ID হবে।

Julian Day: label-এর নিচে continuous identity

Julian Day Number বা Julian Date calendar label নয়; এটি astronomical day count। Julian calendar-এর সঙ্গে নাম মিললেও দুটি ধারণা আলাদা। একই instant-কে Julian calendar date, Gregorian calendar date এবং Julian Date—তিনভাবে প্রকাশ করা যায়।

Research record-এ অন্তত নিচের representation রাখুন:

• jd_ut—UT-based Julian Date;
• utc_iso—সম্ভব হলে ISO timestamp;
• local_wall_time—স্থানীয় ঘড়ির সময়;
• calendar_system—Julian, Gregorian বা proleptic Gregorian;
• calendar_label—মানুষের পড়ার date;
• day_boundary—midnight, sunrise বা sunset;
• time_precision—day, ghaṭikā, minute বা second।

Julian Day conversion-এ noon boundary-এর কারণে ০.৫ দিনের ভুল খুব সাধারণ। Engine যদি civil midnight থেকে JD গণনা করে আর অন্য component astronomical noon convention ধরে, result ১২ ঘণ্টা সরে যেতে পারে। Unit test-এ known midnight/noon pairs রাখুন।

স্থান, timezone ও historical civil time

Panjika calculation location-sensitive। Sunrise, sunset, moonrise, lagna, eclipse visibility, day-boundary festival rule এবং local saṅkrānti display—সব location বা timezone-এ বদলাতে পারে। “Kolkata time” লিখলেই যথেষ্ট নয়; coordinates ও timezone rule দরকার।

IANA time-zone database modern civil-time software-এর ভিত্তি, কিন্তু তার pre-1970 records সব অঞ্চলের জন্য সমান নির্ভুল নয়; একটি named zone-এর early data কখনো representative city-এর জন্য বেশি নির্ভরযোগ্য। বহু পুরোনো date-এ modern timezone ID retrospective convention মাত্র। তাই ৫৯৪ খ্রিস্টাব্দের local time-কে “Asia/Dhaka-এর ঐতিহাসিক সরকারি সময়” বলা যাবে না।

প্রাচীন calculation-এর জন্য তিনটি স্বচ্ছ option:

1. Local Mean Time: longitude × ৪ মিনিট প্রতি degree;
2. Fixed research offset: report-এ “assumed” label-সহ;
3. Timezone database: available historical rules, version প্রকাশ করে।

Calculation profile ঘোষণা না করলে result অসম্পূর্ণ

এই project-এ একাধিক legitimate calculation branch আছে। URL বা report title-এ শুধু “Panjika” লিখলে কোন branch ব্যবহার হয়েছে বোঝা যায় না। প্রতিটি result-এর সঙ্গে profile ID রাখুন:

Profile-এর মধ্যে constants, rules ও dependency flags immutable রাখুন। UI checkbox বদলালে নতুন profile ID বা parameter manifest তৈরি হবে। বিশেষ করে Modern Fit correction historical planets, tithi, nakṣatra, yoga, karaṇa বা eclipse branch-এ প্রবেশ করছে কি না automated test-এ আটকাতে হবে।

অনিশ্চয়তা লুকিয়ে না রেখে শ্রেণিবদ্ধ করুন

Historical report-এ সব value একই certainty-র নয়। Printed saṅkrānti time স্পষ্ট পড়া গেলেও বইয়ের location অজানা হতে পারে; date label বোঝা গেলেও time unit-এর exact interpretation অনিশ্চিত হতে পারে।

Time precision source-এর চেয়ে বাড়াবেন না। বইয়ে শুধু “দিবা ১০ ঘণ্টা” থাকলে software output “10:00:00” দেখাতে পারে, কিন্তু seconds শূন্য মানে source exact second দিয়েছে—এমন impression তৈরি হয়। Output হওয়া উচিত “প্রায় ১০টা; source precision: hour”।

Confidence score-এর সঙ্গে কারণ রাখুন:

{
  "confidence": "medium",
  "reasons": [
    "last digit partly damaged",
    "calendar system not printed",
    "weekday supports Julian reading"
  ],
  "alternative_readings": ["31", "37"]
}

Provenance ও version manifest

Provenance হলো কোনো data বা result তৈরিতে ব্যবহৃত entity, activity এবং responsible person/software-এর সম্পর্ক। একটি Panjika result-এর provenance chain হতে পারে:

প্রতিটি batch export-এর পাশে একটি machine-readable manifest রাখুন:

{
  "dataset_id": "bengali-calendar-1-1433-v1",
  "generated_at_utc": "2026-10-07T20:00:00Z",
  "code_version": "web-v37.2",
  "profile_id": "ss-historical-v1",
  "engine": "SuryaSiddhantaEngine",
  "bija_profile": "canonical-pancanga314",
  "location": {
    "name": "Dhaka",
    "latitude": 23.8103,
    "longitude": 90.4125
  },
  "time_convention": "local-mean-time-for-ancient-dates",
  "calendar_display": "dual-julian-proleptic-gregorian",
  "source_dataset_version": "research-sources-2026-10-07",
  "files": [
    { "name": "1.html", "sha256": "..." },
    { "name": "2.html", "sha256": "..." }
  ]
}

Version label শুধু “latest” হলে ভবিষ্যতে পুরোনো result recreate করা যাবে না। Code commit, release number, correction-table version, ephemeris files, timezone database version এবং input-data checksum সংরক্ষণ করুন।

Printed source ও software result তুলনার table

একটি single value দেখে engine tune না করে structured comparison dataset বানান:

Difference সবসময় error নয়। সেটি ভিন্ন location, Bīja table, epoch, ayanāṃśa, sunrise definition, calendar label বা printing convention-এর ফল হতে পারে। আগে cause classify করুন, পরে calibration বিবেচনা করুন।

Golden tests ও regression archive

Historical source থেকে যাচাইকৃত কিছু case golden test হিসেবে রাখুন। তবে test-এ শুধু final Bengali date নয়; intermediate values-ও সংরক্ষণ করুন:

• UTC/JD এবং local-time convention;
• ahargana ও deśāntara;
• raw ও Bīja-corrected revolution constants;
• mean Sun, manda correction ও true Sun;
• saṅkrānti bracket এবং root;
• sunrise, next sunrise ও applied month-start rule;
• final Bengali date এবং displayed J/G labels।

Batch validation-এর গুরুত্বপূর্ণ boundary:

1. বাংলা বছর ১ এবং minimum supported date;
2. Gregorian reform display boundary ১৫৮২;
3. বাংলা বছর ৯৮৯-এর irregular civil-label sequence;
4. British ১৭৫২ cutover display;
5. Modern Fit cutoff ১৯৪৬/১৯৪৭;
6. Leap years ও month length ২৭–৩৫ day guard;
7. ৩৫৯°/০° solar-longitude wrap;
8. Dhaka, Kolkata ও New York timezone/DST cases;
9. Julian Date to DateTime supported-range boundary;
10. HTML, XML ও on-screen report-এর consistency।

কোনো historical exception manually insert করলে data patch-এ reason, source, affected range এবং author রাখুন। Code-এর মধ্যে unlabelled if (year == 989) ভবিষ্যৎ researcher-এর কাছে ব্যাখ্যাতীত হয়ে যাবে।

HTML, XML ও public archive-এ কী প্রকাশ করবেন?

Public calendar সহজপাঠ্য হতে পারে, কিন্তু research metadata লুকিয়ে রাখা উচিত নয়। Page footer বা “গণনার তথ্য” expandable section-এ দিন:

• Calculation method ও profile ID;
• Location, coordinates ও timezone convention;
• Julian/Gregorian display policy;
• Engine ও dataset version;
• Generated timestamp;
• Source citations ও scan links;
• Known uncertainty বা exception note;
• Permanent record ID বা checksum।

XML export-এ human-readable CDATA-এর পাশাপাশি machine-readable attributes রাখলে দুই ধরনের ব্যবহার সম্ভব:

<panji id="by-989-day-001"
       bengali_year="989"
       jd_ut="2299160.5"
       calendar_policy="dual-julian-gregorian"
       profile="ss-historical-v1"
       source_confidence="medium">
  <dates julian="..." gregorian="..." />
  <source ref="book-edition-page" />
  <note><![CDATA[Historical calendar transition note...]]></note>
</panji>

Source scan publicভাবে দেওয়া না গেলে অন্তত bibliographic reference ও private repository identifier দিন। Copyright restriction calculation metadata প্রকাশে বাধা নয়, কিন্তু image reuse-এর permission আলাদা বিষয়।

একটি সম্পূর্ণ historical verification record

ধরা যাক, একটি পুরোনো Panjika-তে মেষ সংক্রান্তির সময় পরীক্ষা করা হচ্ছে। একটি ভালো record-এর narrative হবে:

অমুক পঞ্জিকার অমুক সংস্করণ, অমুক পৃষ্ঠা থেকে সংক্রান্তির মুদ্রিত পাঠ নেওয়া হয়েছে। Source date-টি Julian না Gregorian—বইয়ে বলা নেই; weekday ও regional publication history থেকে দুটি interpretation পরীক্ষা করা হয়েছে। Calculation profile ss-historical-v1, canonical Bīja এবং ঘোষিত location convention ব্যবহার করেছে। Result একই instant-এর Julian ও proleptic Gregorian label-এ দেখানো হয়েছে। Printed time-এর unit conversion rule আলাদাভাবে নথিভুক্ত। Scan-এর শেষ digit অস্পষ্ট হওয়ায় reading confidence “medium”; বিকল্প reading-টিও record-এ রাখা হয়েছে।

এই narrative-এর প্রতিটি claim structured field-এর সঙ্গে যুক্ত থাকলে search, filtering ও automated comparison সম্ভব। শুধু prose note থাকলে মানুষ পড়তে পারে, কিন্তু হাজার বছরের batch analysis কঠিন হয়।

প্রকাশের আগে research checklist

1. Source edition, page ও scan identifier আছে?
2. Original reading আলাদা field-এ অক্ষত আছে?
3. Normalization বা correction rule documented?
4. Date-এর calendar system স্পষ্ট?
5. Dual date হলে একই JD/instant থেকে তৈরি?
6. Location ও coordinates প্রকাশিত?
7. Timezone, Local Mean Time বা fixed offset policy স্পষ্ট?
8. Day boundary—midnight, sunrise বা sunset—ঘোষিত?
9. Calculation profile এবং engine version আছে?
10. Bīja ও Modern Fit correction scope আলাদা?
11. Dependency versions—Swiss Ephemeris/TZDB/data cache—লিপিবদ্ধ?
12. Source precision-এর চেয়ে output precision কৃত্রিমভাবে বাড়েনি?
13. Uncertain reading-এর alternative সংরক্ষিত?
14. Golden test ও boundary regression pass করেছে?
15. Batch manifest ও file checksums তৈরি হয়েছে?
16. HTML এবং XML একই raw record থেকে render হয়েছে?
17. Manual exception source citation-সহ data patch হিসেবে আছে?
18. Public page-এ research limitation দৃশ্যমান?

উপসংহার

ঐতিহাসিক পঞ্জিকা গবেষণায় software-এর কাজ পুরোনো বইকে “সংশোধন” করা নয়; বরং বইয়ের পাঠ, গবেষকের interpretation এবং declared calculation model-কে আলাদা রেখে তাদের তুলনা করা। Original scan ও transcription অক্ষত থাকলে নতুন evidence এলে পুরোনো সিদ্ধান্ত পুনর্বিবেচনা করা যায়।

Calendar label, location, historical time convention, day boundary, Bīja profile ও engine version ছাড়া একটি date বা saṅkrānti time গবেষণার জন্য অসম্পূর্ণ। Continuous Julian Day-এর ওপর dual Julian/Gregorian label বসানো early-year archive-কে modern reader-এর কাছে বোধগম্য করে, আবার original chronology-ও হারায় না।

সবশেষে, reproducibility মানে শুধু একই HTML আবার বানানো নয়। একই source bytes, transcription version, input, profile ও code দিয়ে একই raw astronomical and calendrical result তৈরি করা—এবং প্রতিটি displayed value কোথা থেকে এসেছে তা দেখাতে পারাই প্রকৃত পুনরুৎপাদনযোগ্যতা।

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

1. W3C—PROV-O: The PROV Ontology; data provenance-এর entity, activity ও agent model.
2. W3C—PROV Overview; provenance family-এর ধারণাগত পরিচয়।
3. Wilkinson et al.—The FAIR Guiding Principles for scientific data management and stewardship, Scientific Data 3, 160018 (2016).
4. IANA Time Zone Database—Theory and pragmatics; pre-1970 data ও historical-time limitations.
5. IETF RFC 6557—Procedures for Maintaining the Time Zone Database.
6. U.S. National Archives—Preserving the integrity of original records, including mistakes.
7. M. Yano ও M. Fushimi—Pancanga 3.14 program notes; traditional Surya Siddhanta model ও version history.
8. Astrodienst—Swiss Ephemeris Programmer’s Documentation; time scales, flags ও reproducible ephemeris comparison.
9. সূর্য সিদ্ধান্ত পঞ্জিকা project research archive; historical Bengali year export, dual J/G policy, Modern Fit correction table, source scans এবং regression records.