The Short Version
Tithi, Nakshatra, Yoga, and Karana are derived from astronomical positions and interpreted through Panchang conventions. They are not simple labels attached to a date; they can change during the day, and the value considered important for a Panchang day is often tied to sunrise rules.
For developers, the key habit is to test the same date across the locations and traditions your product supports, then display metadata clearly enough that support teams can explain differences.
The Core Lunar Fields
- Tithi: the lunar day, based on angular separation between the Moon and Sun.
- Nakshatra: the lunar mansion occupied by the Moon in the sidereal system.
- Yoga: a Panchang element derived from the combined longitudes used by the calendar system.
- Karana: half of a Tithi, commonly used in traditional Panchang interpretation.
These values are often consumed by astrology apps, devotional platforms, muhurat tools, regional content sites, and calendar products. Their meaning is strongest when date, place, timezone, and calendar convention are all understood together.
A field can transition close to sunrise, during business hours, or near the end of the civil day. That is why a production UI should avoid assuming a single date label explains the full story.
Why Sunrise Matters
Panchang days are not always interpreted like midnight-to-midnight product calendars. In many contexts, the Tithi in effect at sunrise is especially important. If a transition happens near sunrise, two reference sources may appear to disagree unless they are using the same location, timezone, ayanamsa, and rule convention.
When debugging user reports, collect the city, date, expected value, observed value, and the reference source. That gives the team enough context to decide whether the difference is a real mismatch or a known convention difference.
Calendar Conventions and Ayanamsa
DevDarsha v1.0 uses the Purnimanta system and Lahiri 1955 ayanamsa. API responses expose convention metadata so integrations can understand which system produced the output.
This matters because alternate sources may use Amanta naming, another ayanamsa, or different regional observance rules. The underlying astronomy may be close while the presented calendar result differs in a way that is expected for that source.
When you store or display Panchang output, keep the useful response metadata nearby: engine version, resolved timezone, calendar system, ayanamsa, request ID, and cache information where available.
How Developers Should Test
Start with stable dates, then add edge cases. Test a normal weekday, a known festival date, a date with a transition near sunrise, and a location your users care about. If your app supports multiple regions, test at least one city per supported region before go-live.
- Compare daily endpoint results in Playground before writing UI assumptions.
- Test the same date in multiple cities when location can affect timings.
- Check how your UI renders field changes, missing plan-gated fields, and explanatory copy.
- Use
X-Request-IDwhen reporting a mismatch or debugging production behavior.
Display Guidance
Show the field name, value, relevant timing when available, and the resolved location/timezone. For consumer apps, explain that Panchang sources can differ due to calendar system, ayanamsa, and regional rules. That copy prevents expected variation from looking like a software bug.