Verify Vimshottari Dasha Against DrikPanchang: A Developer Guide

Vimshottari Dasha is the 120 year planetary period system that drives most prediction work in Jyotish. It is also the calculation most likely to disagree between two Vedic APIs even when both claim Lahiri ayanamsa. The cause is rarely the dasha math itself. It is upstream: timezone parsing, Moon longitude precision, and the year-length convention used to convert nakshatra fractions into calendar days. By the end of this post you will know the two dominant failure modes, how to cross-check against DrikPanchang, and how to lock the result into a regression test.

What is Vimshottari Dasha and why is it so hard to verify

Vimshottari Dasha assigns a ruling graha to every period of life, starting from the Moon nakshatra at birth. The 120 year cycle is split across nine planets in a fixed sequence (Ketu 7, Venus 20, Sun 6, Moon 10, Mars 7, Rahu 18, Jupiter 16, Saturn 19, Mercury 17). The first Mahadasha at birth is partial: the fraction of the natal nakshatra already traversed by the Moon sets how much of that first period has already elapsed. Every downstream Mahadasha, Antardasha, and Pratyantardasha boundary cascades from that single Moon longitude reading.

That cascade is what makes Vimshottari a sensitive test of upstream correctness. Each nakshatra spans 13 degrees 20 arcminutes (800 arcminutes total). A 6 arcminute drift in Moon longitude shifts the nakshatra fraction by 0.0075, which over a 20 year Venus Mahadasha is 55 days. A 60 minute timezone slip can move the Moon by 30 arcminutes, enough to land in the next nakshatra and change the starting dasha lord. Cross-check against a canonical Vedic source rather than trust one API in isolation.

Ready to ship dashas your users can trust? The Vedic Astrology API returns Mahadasha, Antardasha, and Pratyantardasha periods verified against authoritative sources. See pricing.

How timezone bugs at pre-dawn births corrupt the starting nakshatra

The most common silent failure mode is a timezone conversion bug that surfaces only for births in the pre-dawn window (roughly 00:00 to 05:30 local in the Indian Standard Time band). When the local birth time falls before the UTC day boundary, naive integer arithmetic on the offset can drop or add a full hour to the UTC instant. The Moon moves about 0.5 degree per hour, so a 60 minute error shifts Moon longitude by about 30 arcminutes. For a Moon sitting near a nakshatra boundary, that is enough to flip the starting dasha lord. The Lagna shifts by roughly 15 degrees in the same window, which usually changes the ascending sign entirely.

The fix is conceptual, not clever. Treat the local time and the UTC offset as a single signed minute count, hand the total to the date constructor, and let it normalize overflow on its own. Never decompose into hours and remainders mid-flight, because integer floor and modulo have inconsistent sign conventions for negative quotients. A naive pre-dawn IST birth that calculates Moon longitude an hour off will produce dasha boundaries that are wrong by months, not minutes. Test your code with one birth at 02:30 IST and one at 14:30 IST, same date, same location. If the Moon longitude difference is not roughly 6.5 degrees (12 hours times 0.55 degrees per hour), your timezone path is broken.

Why a 60 day Mahadasha drift means your API uses Savana 360

Vimshottari uses a solar year of 365.25 days, not the Savana civil year of 360 days that older Vedanga Jyotisha texts reference. Some libraries quietly default to 360 because the math is cleaner: 18 year Rahu Mahadasha becomes exactly 6480 days, every period rounds nicely. The problem is that DrikPanchang and every other reference platform Vedic practitioners actually use have settled on 365.25. If your API uses Savana 360 you will see a consistent drift of about 1.46 percent on every period boundary, which compounds visibly.

The way this appears in customer reports is unmistakable. The user sends a screenshot of DrikPanchang Kundli and your output side by side. The Mahadasha lord names agree. The order agrees. Every transition date is off by 60 to 100 days, scaling with how far from birth the transition is. The first Mahadasha balance looks correct because the relative fraction is preserved; only the absolute day count drifts. If you see this pattern, the fix is one constant: replace 360 with 365.25 in the days-per-year used by your dasha balance calculation. The two-epoch test in the verification recipe below catches this regression on every commit.

How to verify a Vimshottari Dasha API against DrikPanchang

The verification recipe is four steps, in order. Do not skip any of them, because each catches a different class of failure that the next cannot.

1. Pick a stable test birth. Use Mumbai 1985-04-15 06:00 IST, latitude 19.0760, longitude 72.8777. Pre-1990 helps catch DST and historical timezone bugs. A 06:00 IST birth sits close enough to sunrise to surface pre-dawn timezone bugs without being so early that DrikPanchang itself struggles.
2. Compute Moon nakshatra and pada. Call your nakshatra endpoint or extract Moon longitude from your birth chart endpoint. Open the DrikPanchang Kundli page, enter the same birth, and compare. The nakshatra name and pada number must match exactly. If they do not, stop here. Your problem is upstream of dasha, in Moon longitude or ayanamsa, not in the dasha logic.
3. Cross-check the first three Mahadasha boundaries. Compare the end dates for the partial first Mahadasha and the two following Mahadashas (typically Saturn into Mercury into Ketu, depending on starting lord). DrikPanchang lists dates and times. A discrepancy under 2 days is normal precision noise from Moon longitude rounding. A discrepancy of 50 to 100 days is the Savana 360 bug. An hour-scale or day-scale shift in only pre-dawn births is the timezone parsing bug.
4. Write the regression test. Hardcode the expected Mahadasha end dates from DrikPanchang for two births at very different epochs. The 360 vs 365.25 ratio is 1.0146, close to 1, which means single-case verification can mask the bug if the case happens to land on a compensating Moon position. Two epochs at least a decade apart catch it reliably.

How to call the dasha endpoint and verify field-by-field

The developer flow always starts with geocoding so latitude, longitude, and timezone come from one source. Pass the result straight into the dasha call. The response includes the birth Moon nakshatra and pada (moonNakshatra, nakshatraName, nakshatraLord), the partial first-Mahadasha balance (birthDashaBalance), and all nine Mahadashas in order with startDate and endDate strings formatted in the requested timezone.

# Step 1: geocode Mumbai to get latitude, longitude, timezone
curl "https://roxyapi.com/api/v2/location/search?q=mumbai&limit=1" \
  -H "X-API-Key: YOUR_KEY"

# Step 2: feed the result into /vedic-astrology/dasha/major
curl -X POST "https://roxyapi.com/api/v2/vedic-astrology/dasha/major" \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "date": "1985-04-15",
    "time": "06:00:00",
    "latitude": 19.0760,
    "longitude": 72.8777,
    "timezone": "Asia/Kolkata"
  }'

import { Roxy } from '@roxyapi/sdk';

const roxy = new Roxy({ apiKey: process.env.ROXY_API_KEY });

const { data: loc } = await roxy.location.searchCities({ q: 'mumbai', limit: 1 });
const city = loc.cities[0];

const { data: dasha } = await roxy.vedicAstrology.getMajorDashas({
  date: '1985-04-15',
  time: '06:00:00',
  latitude: city.latitude,
  longitude: city.longitude,
  timezone: city.timezone,
});

console.log(dasha.nakshatraName, dasha.nakshatraLord);
dasha.mahadashas.forEach(m => console.log(m.planet, m.startDate, m.endDate));

from roxy_sdk import Roxy

roxy = Roxy(api_key=os.environ["ROXY_API_KEY"])

loc = roxy.location.search_cities(q="london", limit=1)
city = loc["cities"][0]

dasha = roxy.vedic_astrology.get_major_dashas(
    date="1985-04-15",
    time="06:00:00",
    latitude=city["latitude"],
    longitude=city["longitude"],
    timezone=city["timezone"],
)

print(dasha["nakshatraName"], dasha["nakshatraLord"])
for m in dasha["mahadashas"]:
    print(m["planet"], m["startDate"], m["endDate"])

The boundary dates in the response are the only thing you should be comparing against DrikPanchang. The Moon nakshatra and pada are upstream signals: if they match, dasha math is the only remaining variable. See POST /vedic-astrology/dasha/major for the full request and response schema. For deep background on the system itself, the Vimshottari Dasha predictions guide explains period interpretations. The accuracy verification methodology used across all Vedic endpoints is documented at methodology.

FAQ

Why does my dasha API differ from DrikPanchang by exactly 60 days on every period?

The most likely cause is a year-length convention mismatch. DrikPanchang and most modern Vedic platforms use the solar year of 365.25 days for Vimshottari. Some libraries default to the Savana civil year of 360 days from older texts. That 1.46 percent ratio produces about 95 days of drift on an 18 year Rahu Mahadasha, 105 days on a 20 year Venus Mahadasha. The drift is consistent across every period because it is a single constant in the calculation.

Why does my dasha output differ by an hour for pre-dawn births only?

This is a timezone parsing bug at the UTC day boundary. When local birth time is before roughly 05:30 IST, decomposing the offset into integer hours plus minutes can introduce a one hour error because floor and modulo behave differently for negative quotients. The Moon moves about 0.5 degree per hour, so an hour shift moves Moon longitude enough to land in a different nakshatra near boundaries. Pass the total signed minute count to the date constructor and let it normalize.

Does Vimshottari use a 360 day or 365.25 day year?

In practice, every reference Vedic platform uses 365.25, the solar year. The 360 day Savana convention comes from older Vedanga Jyotisha and Surya Siddhanta texts but does not match DrikPanchang or any production Indian Vedic software in widespread use. If you cite a classical source for 360, you will need a flag for users who expect DrikPanchang-compatible output. The pragmatic default for any new dasha API in 2026 is 365.25.

How do I test my dasha API systematically across timezones and epochs?

Hardcode expected DrikPanchang outputs for at least two births at different epochs (one pre-1990, one post-2020) and very different latitudes. Compare nakshatraName, nakshatraLord, and the first three Mahadasha boundary dates per fixture. Allow under 2 days of tolerance on boundary dates to absorb Moon longitude precision noise. Run on every commit. Single-case tests can mask the Savana vs solar bug because the 1.46 percent ratio can be compensated by a small Moon offset at certain birth epochs.

What is Lahiri ayanamsa and why does it matter for dasha?

Lahiri (Chitrapaksha) is the official Indian government ayanamsa, the offset between tropical and sidereal zodiacs published by the Calendar Reform Committee. DrikPanchang uses Lahiri by default. Vimshottari Dasha runs on sidereal Moon longitude, so the ayanamsa choice directly shifts the natal nakshatra. A KP or Raman ayanamsa will move Moon longitude by minutes, occasionally crossing a nakshatra boundary and changing the entire dasha sequence. Always verify which ayanamsa your API and your reference platform are using before assuming a mismatch is a bug.

Can I trust my Vimshottari dasha API for births before 1948?

Only if the timezone resolver is historical. India unified Bombay Time and Calcutta Time into IST on 1948-09-30, and ran wartime DST from 1942 to 1945. A naive offset of plus 5.5 will be wrong for any pre-1948 Indian birth. Use an IANA timezone string (Asia/Kolkata) and a tzdata-backed resolver that returns the historically correct offset for the birth date. The dasha math itself is epoch-agnostic, but it inherits whatever Moon longitude the upstream timezone path produced.

Why are Moon longitude differences amplified in dasha boundaries?

Because Vimshottari converts a fractional nakshatra position into calendar years, then multiplies by Mahadasha length. The Moon traverses each nakshatra in roughly 24 hours, but the resulting period can span 20 years. The amplification ratio is about 7300 to 1: a one arcminute Moon error becomes a five day boundary shift. This is why ayanamsa precision and timezone parsing matter more for dasha than for any other Vedic calculation, including the natal chart.

What free tools verify Vimshottari dasha calculations?

DrikPanchang Kundli is the standard reference for Lahiri Vimshottari output. JyotishApp and onlinejyotish.com provide independent cross-checks against the same ayanamsa. Always confirm the ayanamsa setting on whichever tool you use before comparing, because dasha boundaries will look wrong if the reference platform is silently using KP or Raman ayanamsa. For systematic verification, hardcode expected outputs from DrikPanchang into your test suite rather than running live comparisons, because UI scraping is brittle and rate-limited.

Conclusion

Vimshottari is leverage-amplifying: small Moon longitude or timezone errors become months of boundary drift. Verify against DrikPanchang on two epochs, lock the expected boundaries into a regression test, and audit your year convention before assuming dasha math is the problem. Build dashas that survive scrutiny with the Vedic Astrology API, verified against DrikPanchang across the full 120 year cycle.