DST and Historical Timezones Break Vedic Kundli Accuracy

About the author: Brajesh Vashisht is a Vedic Astrologer and KP Systems Specialist with 22 years of practice across matrimonial matching, career timing, and muhurta selection. His work draws on formal study of Jyotish Shastra, with research focused on precision event timing using dasha systems, ashtakavarga scoring, and Vedic divisional charts.

If you generate kundli charts for clients born before independence, or for parents and grandparents born in the 1940s, your software is probably wrong. Not by a forgivable arc-second. Wrong by 15 degrees of Ascendant, by a full nakshatra pada on the Moon, and by months of Vimshottari Dasha balance. The cause is mundane. India ran a wartime daylight saving period from 1942 to 1945, and the country did not finish unifying its civil time into a single Indian Standard Time until 1955, when Bombay Time was the last regional offset to merge. Most chart software loads the modern +5.5 offset for every Indian birth and trusts the user to know better. Most users do not know better. This guide shows the broken case, the corrected case using a historical timezone resolver, and the request shape that gets it right every time.

How does India wartime DST corrupt Vedic chart calculations?

The corruption is silent because the input looks innocent. A Jyotishi types 1944-06-15 and 06:00:00, picks Asia/Kolkata from a dropdown, and the chart software converts that to UTC using the present-day offset of +5.5 hours. That returns 00:30 UTC. In June 1944, however, India was on Indian War Time, which ran +6.5 hours from UTC. The actual UTC moment of birth was 23:30 on 1944-06-14. The software has placed the birth one full hour too late. Every downstream calculation that depends on sidereal time inherits the error: Lagna, house cusps, divisional chart sign placements, KP sub-lord boundaries, Vimshottari Dasha balance derived from Moon nakshatra position. Jupiter or Saturn moving by 60 arc-seconds per day will not flip a sign. The Lagna moves by 1 degree every 4 minutes. A 60 minute error rotates the Ascendant by approximately 15 degrees, frequently shoving it into the next rashi. Matrimonial matching reports run on this offset will silently mis-classify Manglik status, Bhakoot, and Nadi Koota.

Which date ranges still need historical timezone resolution?

The wartime DST issue is not only an Indian problem. Several South Asian regions ran short, often poorly documented DST experiments that the tz database tracks with date-keyed precision. The table below lists every range a Jyotishi or developer needs to know when working with subcontinent births and family histories. Each entry shows the IANA zone name, the date range, and the offset that was in force during that range. Pass the IANA string to the Vedic chart endpoint and the resolver picks the right one. Pass a hardcoded number and you will get the modern offset whether the date warrants it or not. Calcutta Time (UTC+5:53:20) merged into IST in 1948, and Bombay Time (UTC+4:51) drifted on its own offset until the final 1955 unification into IST at +5:30. Charts cast for Mumbai before 1955, or Kolkata before 1948, using a flat +5.5 offset are off by minutes that compound into nakshatra-boundary errors on the Moon.

Anyone serving the South Asian diaspora across these windows needs an IANA-aware resolver in the path. The methodology page documents how the resolver is wired into every chart endpoint and why offset coercion happens at request validation, not in the handler. Want to build kundli features without writing this layer yourself? Start with the Vedic Astrology API and skip the historical-resolver build entirely.

What does the broken vs corrected ascendant look like?

The numbers play out the same way for every chart in the wartime window. The 60 minute offset difference between the modern resolver default and the actually-correct wartime offset translates to about 900 arc-minutes of Lagna shift, which is roughly 15 degrees of zodiac at typical Indian latitudes. For a 1944-06-15 06:00 Delhi birth, the corrected Lagna is approximately 09 degrees of Gemini with Mrigashira nakshatra. The broken Lagna lands near 24 degrees Gemini with Punarvasu nakshatra. Two different nakshatras, two different padas, two different Navamsa signs. If a matrimonial software runs Bhakoot or Nadi Koota off the broken chart, the recommendation is meaningless. If a KP horary software derives the cusp sub-lord from the broken chart, the entire significator chain is wrong. The fix is one input field, but the consequences of getting it wrong cascade through every prediction layer above the birth chart. This is why the timezone handling guide makes IANA strings the only recommended path for any production kundli pipeline.

How to call the Vedic chart endpoint with historical timezones

The pattern is two calls. First geocode the city to get the IANA zone. Second post the birth data with that zone string in the timezone field. The chart endpoint validates the input, recognizes the IANA string, looks up the offset that was in force on the supplied date, and applies it before any sidereal computation. You never hand-pick the offset.

# step 1: resolve the city
curl -s "https://roxyapi.com/api/v2/location/search?q=new%20delhi" \
  -H "X-API-Key: $ROXY_API_KEY"

# step 2: cast the chart with the IANA string from cities[0].timezone
curl -s "https://roxyapi.com/api/v2/vedic-astrology/birth-chart" \
  -H "X-API-Key: $ROXY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "date": "1944-06-15",
    "time": "06:00:00",
    "latitude": 28.6139,
    "longitude": 77.209,
    "timezone": "Asia/Kolkata"
  }'

const apiKey = process.env.ROXY_API_KEY;
const base = "https://roxyapi.com/api/v2";

const loc = await fetch(`${base}/location/search?q=new%20delhi`, {
  headers: { "X-API-Key": apiKey },
}).then((r) => r.json());

const city = loc.cities[0];

const chart = await fetch(`${base}/vedic-astrology/birth-chart`, {
  method: "POST",
  headers: {
    "X-API-Key": apiKey,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    date: "1944-06-15",
    time: "06:00:00",
    latitude: city.latitude,
    longitude: city.longitude,
    timezone: city.timezone,
  }),
}).then((r) => r.json());

console.log(chart.meta.Lagna);

import os
import requests

api_key = os.environ["ROXY_API_KEY"]
base = "https://roxyapi.com/api/v2"
headers = {"X-API-Key": api_key}

loc = requests.get(
    f"{base}/location/search",
    params={"q": "new delhi"},
    headers=headers,
).json()
city = loc["cities"][0]

chart = requests.post(
    f"{base}/vedic-astrology/birth-chart",
    headers={**headers, "Content-Type": "application/json"},
    json={
        "date": "1944-06-15",
        "time": "06:00:00",
        "latitude": city["latitude"],
        "longitude": city["longitude"],
        "timezone": city["timezone"],
    },
).json()

print(chart["meta"]["Lagna"])

The deep link is POST /vedic-astrology/birth-chart. Note the timezone field in the route schema accepts both an IANA string and a numeric offset. The string is the safe default for any historical birth. The numeric offset is convenient only when the caller already knows the historically correct value, which is rarely true for births before 1948 in India, before 2002 cutoff windows in Pakistan, or before 2009 in Bangladesh. The handler always receives a coerced numeric offset, so internally the math is identical. The difference is at the boundary, where the IANA string pulls from the tz database and the numeric input is trusted as-is.

Which other South Asian regions need the same treatment?

The wartime DST pattern is not an Indian peculiarity. Pakistan ran a six month DST experiment in 2002 from April to October, then repeated DST in 2008 (June to November) and 2009 (April to November). Bangladesh adopted a single DST year in 2009, advancing clocks one hour from 2009-06-19 through 2009-12-31. Sri Lanka shifted from +6:00 to +5:30 on 1996-05-25 and to +6:00 then back to +5:30 again. Nepal moved its civil offset to +5:45 in 1986. Myanmar settled at +6:30 in 1942. Every one of these adjustments lands in family-history birth windows that practitioners actually serve. The same rule applies. Pass the IANA string for the country and let the resolver pick the offset for the date. Asia/Karachi handles Pakistan correctly. Asia/Dhaka handles Bangladesh. Asia/Colombo handles Sri Lanka. Asia/Kathmandu handles Nepal. Asia/Yangon handles Myanmar. Hardcoded numbers handle nothing correctly across these boundaries. The why-two-kundlis-disagree post covers the broader debugging matrix when two pieces of software return different charts for the same input. Timezone resolution is the most common culprit, and it is also the easiest to fix once the IANA-string discipline is in place.

FAQ

What is wartime DST and why does it matter for Vedic kundli accuracy?

Wartime DST refers to daylight saving periods adopted by countries during World War II. India ran Indian War Time at UTC+6:30 from 1942-09-01 to 1945-10-15. A kundli generated for a birth in that window with a hardcoded +5.5 offset places the chart one full hour late, rotating the Lagna by roughly 15 degrees and shifting Moon nakshatra placement. The fix is to use an IANA timezone string so the resolver picks the offset that was in force on the birth date.

How do I cast a kundli for a pre-1948 Indian birth?

Pass the IANA string Asia/Kolkata in the timezone field of the Vedic birth chart endpoint, along with date, time, latitude, and longitude. The endpoint resolves the IANA name against the historical tz database. For 1944-06-15 06:00 in New Delhi the resolver applies UTC+6:30 wartime offset. For a 1947 birth in Bombay it applies the Bombay local mean time offset of about UTC+4:51 if before 1955, then UTC+5:30 IST after.

Does the RoxyAPI Vedic chart endpoint accept IANA timezone strings?

Yes. The timezone field on the Vedic birth chart endpoint accepts either an IANA identifier (Asia/Kolkata, Asia/Karachi, Asia/Dhaka, America/New_York) or a numeric UTC offset (5.5, 6, minus 5). When you pass an IANA string the server resolves it to the offset that was historically correct for the birth date. When you pass a number the server uses that number directly with no historical lookup. For any birth before recent decades, prefer the IANA string.

Why is the Lagna shift roughly 15 degrees for a 1 hour offset error?

The Ascendant moves by approximately 1 degree of zodiac every 4 minutes of sidereal time. A 60 minute error in the assumed birth offset translates into about 60 divided by 4, or 15 degrees of Lagna shift. That is enough to push the Ascendant into the next rashi for a non-trivial fraction of birth times. Since divisional charts and KP cusp sub-lords are derived from the Lagna, a 15 degree error cascades into D9 sign changes, sub-lord boundary crossings, and Bhakoot or Nadi Koota miscalculations.

How do I avoid this error in production matrimonial software?

Two rules. First, always call the location search endpoint before any chart endpoint, and feed the cities[0].timezone IANA string straight into the chart request. Never let users type or pick a numeric offset. Second, store the IANA timezone alongside birth date, time, latitude, and longitude in your database. If you store only a numeric offset you lose the ability to recompute charts when tz database revisions clarify historical offsets, which happens roughly twice a year for the South Asian zones.

Which Pakistan and Bangladesh windows need historical resolution?

Pakistan: 2002-04-07 to 2002-10-06, 2008-06-01 to 2008-11-01, and 2009-04-15 to 2009-11-01, all at UTC+6 instead of the standard +5. Bangladesh: 2009-06-19 to 2009-12-31 at UTC+7 instead of +6. Births inside those windows cast with the modern numeric offset land one hour off and inherit the same Lagna and nakshatra distortions described for India wartime DST.

If you build kundli, panchang, or matrimonial software that serves any client born before recent decades, IANA timezone resolution is not a polish item. It is a correctness boundary. Build it on top of an endpoint that already handles wartime DST, partition era offsets, and modern unified time as one consistent rule. Start with the Vedic Astrology API and avoid rolling your own historical resolver.