The Short Version
DevDarsha calculates Panchang data from the date, location, timezone, and supported calendar settings in the request. The API response combines astronomical timing, lunar calendar elements, festival and vrat logic, and derived muhurat windows into a single developer-friendly JSON shape.
Verification is intentionally section-wise. Sunrise and festival checks are not blended into one broad score, and pending areas are described separately. That keeps the public Accuracy page honest and makes the Methodology page easier to evaluate.
This is a public, business-safe explanation. It does not expose internal fixture tables, private validation datasets, exact rule-engine internals, unpublished roadmap items, or implementation-level algorithm details.
What the API Needs Before It Can Calculate
A Panchang response depends on more than a calendar date. The same day can produce different local timings depending on place and timezone, so the API starts from inputs that anchor the calculation to a real observer context.
- Date: the civil date the application wants to evaluate.
- Location: a city identifier or supported coordinate-based lookup, depending on the plan and endpoint.
- Timezone: resolved from the request context or supplied when the integration needs explicit control.
- Calendar conventions: supported systems and filters that shape how results are presented.
The API documentation describes the exact request fields and response envelope. This guide is meant to explain the reasoning behind the data, not replace the endpoint reference.
How Calculation Works at a High Level
DevDarsha separates Panchang output into domains that are easier to reason about and verify independently. Astronomical timings are calculated from date and location. Panchang elements such as tithi, nakshatra, yoga, and karana are derived from the relative positions used by the calendar system. Festival and vrat results are resolved through deterministic observance rules and supported calendar conventions.
Formula-derived windows such as Rahu Kaal, Gulika Kaal, Yamaganda, Abhijit, and Choghadiya are calculated from the relevant day/night timing boundaries. Because these values are derived from other timing inputs, their reliability depends on both the underlying sunrise/sunset data and the consistency of the formula application.
A correct sunrise time does not automatically prove a festival date, and a validated festival date does not automatically prove every muhurat boundary. DevDarsha keeps these layers separate so strengths and pending coverage stay visible.
How DevDarsha Verifies the Output
The public methodology is built around independent verification layers. Each layer uses the most appropriate kind of reference for that data type, then reports its own status instead of hiding behind a single overall claim.
- Astronomical timings: checked against established timing references within a stated tolerance.
- Panchang elements: reviewed against curated Panchang references, with attention to boundary-sensitive cases.
- Vrat and lunar events: evaluated through calendar agreement and observance rules.
- Festival dates: validated against multiple independent calendar references where agreement exists.
- Muhurat timings: checked for formula consistency and timing-boundary behavior.
The latest public snapshot and caveats are on the Accuracy page. The more formal explanation of release gates, agreement sets, and tolerances is on the Methodology page.
How to Read Accuracy Snapshots
Accuracy numbers are dated snapshots, not live guarantees. They describe measured coverage at a point in time, including pass counts, corpus boundaries, and the public validation boundary for the release.
For production decisions, treat the public snapshot as one input. Teams building user-facing calendar, devotional, astrology, or regional content products should still test representative cities, dates, traditions, and display formats before launch.
Recommended Developer Flow
The safest way to onboard is to move from explanation to reference to live testing:
- Read this guide to understand the trust model.
- Use the documentation for request fields, response structure, errors, and plan gates.
- Open the playground to inspect real JSON responses before writing integration code.
- Review pricing once you know whether your product needs daily, monthly, yearly, or higher-volume access.
Before You Go Live
Before shipping, test your important locations, dates, and user-facing display states. Pay special attention to timezone formatting, city selection, festival display rules, empty or pending fields, and user copy around high-risk reliance.
The API is designed for developer-friendly Panchang data, but product teams remain responsible for how results are presented to end users. For ceremonial, legal, financial, medical, or other high-risk decisions, independently verify the output and use appropriate disclaimers.
For high-volume or business-critical integrations, contact DevDarsha with your use case, regions, expected traffic, and the fields your product depends on most.