Ayanamsa (Lahiri)

The sections above give the formula in one line and the value for one date. This part goes further: what the number is measuring, where the word appears in the classical texts and where it does not, each step the engine takes, a year-by-year table, a check of the engine against figures printed in a published book, and a plain account of how much of a chart would move if a different ayanamsa were used. Every figure quoted here came out of the same function the calculator calls, described on the methodology page.

What the number measures

Any position on the zodiac is an angle from a starting point, and there are two starting points in use. The astronomical formulas in this engine produce tropical longitudes, measured from the March equinox. Vedic astrology reads sidereal longitudes, measured from a point held against the stars. The ayanamsa is the angle between those two starting points at a given moment. It is one number for the whole sky: it does not depend on which graha you are looking at, where on Earth you stand, or who you are.

The engine can show the two starting points directly. Its tropical Sun reaches 0° on 20 March 2026, which is the equinox; its sidereal Sun reaches 0° of Aries on 14 April 2026, about twenty-five days later. The same gap appears half a year on: tropical 180° on 23 September 2026, sidereal 0° of Libra on 17 October 2026. Those twenty-five days are the ayanamsa expressed in the Sun's own motion, since the Sun covers a little under one degree a day and the offset for 2026 is a little over 24 degrees. This is the reason a person's Western star sign and the result of the sidereal Sun sign calculator so often differ by one sign.

The Sanskrit vocabulary matches the arithmetic. A longitude that still includes the ayanamsa is called sayana, "with ayana"; one from which it has been removed is nirayana, "without ayana". The case-study book in this project's library prints "Nirayana Bhava" above every chart table for exactly this reason: the columns hold sidereal positions. In this app, every sign, nakshatra and house you see is nirayana.

Where the classical texts use it, and where they are silent

It is easy to assume the old texts define the ayanamsa and give its size. The ones in this project's library do not. Brihat Parashara Hora Shastra uses the word as something the reader is already expected to have. In Ch. 27, on the evaluation of strengths, Sl. 15-17 describe Ayan Bal and begin by telling the astrologer to add the ayanamsa to the graha and then find the Bhuja, which the translation glosses as the distance from the nearest equinox. That is the conversion on this page run in the opposite direction: take a sidereal position, add the offset, and you have a position measured from the equinox. The Shad Bala calculator is where this app reports planetary strength.

BPHS Ch. 28, on Isht and Kasht Balas, does the same thing at Sl. 3-4. For the Sun's Chesht Kendr it asks for three rashis to be added to "Sayan Surya", and the translation adds "i.e. with Ayanamsa". In the very next sentence the Moon's Chesht Kendr is found by deducting the sidereal longitude of the Sun from the Moon. So within two slokas the text moves between the two zodiacs without comment, which tells us the distinction was working knowledge rather than a doctrine that needed stating.

Saravali Ch. 4 Sl. 37 gives Ayana Bala in a simpler form: Venus, Mars, the Sun and Jupiter are strong in Uttarayana, the Moon and Saturn in Dakshinayana, and Mercury in both. Uttarayana and Dakshinayana are the Sun's northern and southern courses, which are tied to the solstices and therefore to the equinox-based frame. Neither Saravali nor BPHS, in the translations held here, states how many degrees the ayanamsa is, how fast it changes, or from what date it is counted. Where the sources are silent this page stays silent too: no classical text is credited with the value the engine uses.

The modern book in the library is more direct about the practical question. The preface to Advanced Predictive Astrology says "The author has followed Lahiri Ayanamsa only" and adds that the Navamsa positions in its examples do not change if the Krishnamurti ayanamsa is used instead, because that one is very close to Lahiri. A publisher's notice in the same book offers tables "based on any Ayanamsha" and names Lahiri, Raman, K.P. and Manu. That is enough to establish two facts from a source: more than one ayanamsa is in circulation, and Lahiri is the one this particular line of published work uses. It is also the only one this app has, as the sources page and the limits above record.

The second name, Chitrapaksha, carries the name of Chitra, one of the twenty-seven nakshatras BPHS lists in Ch. 3. The engine's code uses the label "Lahiri (Chitrapaksha)" and nothing more: it holds the two constants described below and does not compute the position of any star. If you want Chitra as a division of the zodiac rather than as a name, it is the fourteenth nakshatra, running from 23°20′ Virgo to 6°40′ Libra, and it has its own page at Chitra nakshatra.

How the engine computes it, step by step

1. 1.Fix the instant. A typed date in YYYY-MM-DD form becomes 12:00 UTC on that calendar day. A blank field becomes the moment the request arrives. Anything that is not a real calendar date is rejected with an error instead of being rolled forward.
2. 2.Convert the instant to a Julian Day, the continuous day count astronomers use. The routine takes the UTC year, month, day and the fraction of the day from hours, minutes and seconds, and applies the standard Gregorian correction.
3. 3.Subtract 2451545.0, the Julian Day of the epoch J2000.0, which is 12:00 on 1 January 2000. The result is days since the epoch, negative for earlier dates.
4. 4.Divide by 365.25 to turn days into years.
5. 5.Multiply the years by 0.0139601 and add 23.85306. The sum is the ayanamsa in decimal degrees.
6. 6.Return two fields: the instant that was used, as an ISO timestamp, and the degrees. Nothing is rounded on the server.

The whole model is therefore two constants. The first, 23.85306°, is the value at the epoch. The second, 0.0139601° a year, is the rate. Everything else on this page is those two numbers rearranged.

Two details of the method are worth noticing. The year used is 365.25 days, a fixed length, so the "years since 2000" in the formula are a unit of elapsed time rather than calendar years; 1 January 2026 at noon is 26.0014 such years after the epoch, not exactly 26. And the Julian Day routine reads the clock in UTC, so the time zone of your device plays no part once the instant is fixed.

The value across two centuries

The table below is engine output for 12:00 UTC on 1 January of each year. It is the quickest way to see what the offset was at a birth, and how slowly it moves compared with anything else in a chart.

Between the first and last rows, two hundred years apart, the offset grows by 2.79°. A person born in 1950 and a person born in 2026 have charts cast with offsets a little over one degree apart. That is small next to a 30° sign, but it is not small next to the finer divisions discussed further down, which is why the engine always uses the value for the birth instant and never a fixed figure.

How to read what the calculator returns

There is only one kind of successful result, and it has two parts.

• The date. This is the instant the engine actually used, in UTC. If you typed a date it will show that date at 12:00:00. If you left the field blank it will show the moment of the request, to the millisecond. Check it when comparing with another source, because it tells you exactly which instant the figure belongs to.
• The degrees. A decimal number such as 24.227011. The whole part is degrees. Multiply the fraction by 60 for arcminutes, and the fraction of that by 60 for arcseconds: 0.227011 × 60 = 13.62, so 13 arcminutes; 0.62 × 60 = 37, so 37 arcseconds. The value 24.227011 is 24°13′37″.

Most printed almanacs and chart printouts give the ayanamsa in degrees, minutes and seconds, often written with colons, as in 23:34:12. To compare, convert one form to the other; the tables on this page give both. The engine returns many more decimal places than the model can justify. They are there because the server does not round, not because the ayanamsa is known to a millionth of an arcsecond.

The other outcome is a refusal. A date in the wrong format returns "Date must be in YYYY-MM-DD format", and a date that does not exist, such as 31 February, returns "Date is not a real calendar date". The second check exists because the underlying date routine would otherwise turn 31 February silently into early March and answer for a day you never asked about. Future dates are accepted; the line simply continues.

There is no interpretation attached to the figure and there should not be. The ayanamsa is not favourable or unfavourable, has no lord, and says nothing about a person. It is a calibration constant. Its only meaning is what it does to other numbers.

Worked example: converting the sky of one date

Take the example date used above, 15 October 2026 at 12:00 UTC. The engine returns an ayanamsa of 24.2270°. Here is what that does to the two lights, using the engine's own Sun and Moon routines for the same instant.

Follow the Sun. Its tropical longitude is 202.15°, which is 22°09′ into Libra, the seventh sign. Subtract 24.23° and it stands at 177.92°, which is 27°55′ into Virgo, the sixth. The sign has changed because the Sun was less than 24.23° into its tropical sign. For the nakshatra, divide 177.92 by 13.3333: the whole part is 13, and counting from Ashwini as zero that is Chitra. The Sun is 4.59° into Chitra's span, and each pada is 3°20′, so it is in the second pada. The nakshatra calculator performs this same division on the Moon.

The Moon makes the general rule visible. At 17°37′ of tropical Sagittarius it is also less than 24.23° into its sign, so it too drops back one sign, to Scorpio. Any body in the first 24.23° of a tropical sign falls in the previous sidereal sign; any body in the last 5.77° keeps the same sign name. Since 24.23 out of 30 is about 81 per cent, roughly four positions in five carry a different sign name in the two zodiacs for a 2026 date. That figure follows from the offset alone and is the arithmetic behind the article your rashi is not your star sign. You can run the conversion for your own birth with the Moon sign calculator.

One more check on the one-line formula: asking for 16 October 2026 instead returns 24.227049°, which is 0.000038° more than the day before. That is 0.14 arcseconds, the daily change given in the constants table. Nothing else in the chart moves so slowly; the Moon covers that distance in about a quarter of a second.

Checked against figures printed in a book

The working rules of this project forbid calling a calculation right without checking it against something outside the code. For the ayanamsa there is a convenient outside reference in the library itself. Every example chart in Advanced Predictive Astrology has a header giving the birth date and the Lahiri ayanamsa its software used. The text is a scan, so only headers where both the date and the value are clearly legible are used below. The engine was run for 12:00 UTC on each date; the book's figure is for the birth time, but as the offset changes by 0.14 arcseconds a day that mismatch cannot be seen at this precision.

Across nine charts and 375 years, the largest difference is 34 arcseconds, a little over half an arcminute. That is the practical size of the gap between this engine's straight line and a published Lahiri figure. The book's own two extreme values imply a rate as well: from 18°32′30″ in November 1618 to 23°46′23″ in September 1993 is a rise of 5.2314° over about 374.8 years, or roughly 50.24 arcseconds a year, against the engine's 50.256.

Notice also what the table does not show. The differences do not grow steadily away from the year 2000; they are 1 arcsecond in 1905 and 1910, 17 in 1922, 8 in 1979 and about 30 in 1993. A straight line cannot follow a wobble of that kind, which is the limitation the section above states: the formula has no short-period term. This page reports the size of the residual and does not attempt to explain its cause from sources that do not discuss it.

What a different ayanamsa would move

Since every sidereal longitude has the same offset removed, changing the offset slides the whole chart by the same amount. What matters is how wide each division is, because a point changes its label only if the slide carries it across a boundary. If two ayanamsas differ by D arcminutes, the share of all possible positions that change label is D divided by the width of the division.

Read the table with a realistic difference in mind. Against a published Lahiri value the gap found above is about half an arcminute, so roughly one Moon in 1,600 would sit on the other side of a nakshatra boundary. Against a different named ayanamsa the gap is not half an arcminute but whatever separates the two systems, and the share rises in proportion. This app holds no numeric value for any other system, so this page does not quote one; the article why two apps give you two different nakshatras works through the practical cases.

The preface of Advanced Predictive Astrology makes a claim that this arithmetic lets you weigh. It says Navamsa positions in its examples do not change between Lahiri and Krishnamurti. With a Navamsa 200′ wide and a small difference between the two, that will be true for most planets in most charts, and false for one that happens to sit within the difference of a boundary. The engine takes the cautious route for the finest division it offers: the nakshatra sub-lord calculator states that it is not a KP calculation, uses Lahiri like everything else, returns the ayanamsa it used alongside the result, and reports each point's distance to the next boundary so a near miss is visible.

The effect on dasha dates

The ayanamsa also reaches into timing. The Vimshottari sequence starts from how far the Moon has travelled through its nakshatra, and BPHS Ch. 46 Sl. 12-15 assigns each lord a number of years. A nakshatra is 800′ wide, so one arcminute of Moon position is one eight-hundredth of the opening lord's period. Every later date in the sequence moves by the same amount, because the periods follow one another end to end.

So a half-arcminute disagreement about the ayanamsa moves Mahadasha boundaries by a few days at most. That is worth knowing before reading a start date from the Vimshottari Dasha calculator as exact to the day. It is also much smaller than the effect of an uncertain birth time: the engine's Moon is itself stated as accurate to about 0.1°, which is six arcminutes, and the Moon moves about half an arcminute every minute of clock time. The piece on what a Mahadasha is explains the sequence itself.

What does not depend on it

Because the same offset comes off every longitude, anything built from the difference between two longitudes is untouched by the choice of ayanamsa.

• The tithi. It is the Moon's longitude minus the Sun's, divided into steps of 12°. The offset is subtracted from both and cancels, so the elongation is the same angle in either zodiac. The Panchang calculator notes this in its own method.
• The angular distance between any two grahas. Whether two bodies are 5° apart or 120° apart is a fact about the sky, not about where the zodiac is said to begin.
• Sunrise-based time divisions. Rahu Kaal, Choghadiya and the planetary Hora are cut from the interval between sunrise and sunset at a place, which is found from the Sun's altitude and involves no zodiac at all.
• The order of the grahas around the wheel. A uniform slide cannot make one body overtake another.

What does depend on it is everything that names a division: sign, nakshatra, pada, every divisional chart, and whole-sign houses, which are counted from the sign the Ascendant falls in. A house is not an angle between two bodies; it is a label taken from a sign, so it moves with the signs.

Limits, and where birth time comes in

The ayanamsa itself is almost completely insensitive to time. A full day changes it by 0.14 arcseconds; a year by 50. If your birth time is unknown, or even if your birth date were a week out, the offset used for your chart would be the same to well under an arcsecond. Birth-time sensitivity in a chart never comes from this number. It comes from the bodies the number is subtracted from: the Moon moves about 13° a day and the Ascendant about one degree every four minutes. What an unknown time costs is set out in you do not know your exact birth time, and the Lagna calculator shows the case that needs the clock most.

The limits that do belong to this number are about the model, and they are worth stating exactly.

• It is a straight line. The book comparison above shows it sitting within about half an arcminute of printed Lahiri figures from 1618 to 1993, with residuals that go up and down. The line is smooth; the published values are not.
• It is an extrapolation at long range. Run backwards, the line reaches zero 1,708.66 years before J2000. That is a property of the two constants, obtained by dividing one by the other. It is not offered here as the historical date on which the two zodiacs coincided, because none of the sources in this library gives such a date.
• It is the only option. No setting switches the engine to another system. A chart from software set differently will show every position shifted by the difference, uniformly.
• It is not the only source of small disagreements. The positions it is subtracted from are computed with built-in formulas, not a full ephemeris; the engine's header gives the Sun as accurate to about 0.01° and the Moon to about 0.1°, and Rahu is taken from the Moon's mean node. Two programs with an identical ayanamsa can still differ by those amounts. The accuracy page covers how the app reports confidence.

Where this number goes next

Nothing in the app is read directly from the ayanamsa, and nearly everything passes through it. The birth chart calculator subtracts it from the Sun, the Moon, the five planets, Rahu and, when a birth time and place are given, the Ascendant. Each divisional chart starts from those sidereal degrees, so a point near the edge of a narrow division, as in the Navamsa (D9), is the first to feel a change; the article on the Navamsa as the second chart explains why that chart is read so closely.

Transit work uses it in the same way for today's sky. The Gochar calculator places the current positions of the grahas in sidereal signs and counts them from the natal Moon, and the Sade Sati calculator depends on which sidereal sign Saturn occupies. The yearly chart in the Varshaphal calculator looks for the moment the Sun returns to its natal sidereal longitude. Because the offset grows by 0.0139601° each year and the Sun takes about twenty minutes to cover that arc, a sidereal return falls about twenty minutes later each year than a tropical one would, and the two drift further apart over a lifetime.

For the complete picture in one place, the Kundali feature draws the full sidereal chart with its divisional charts, strengths and dashas, all on this one offset. The full list of tools is on the calculators index.

Is the ayanamsa different for different people or places?

No. The handler takes no birth details, no location and no time zone. Two people anywhere on Earth who look up the same instant receive the same figure. What differs between people is the instant of birth, and therefore the value that applied when they were born.

Do the classical texts give this value?

Not the ones in this project's library. BPHS uses the term in Ch. 27 Sl. 15-17 and Ch. 28 Sl. 3-4 as a quantity to be added back to a graha's position, and Saravali Ch. 4 Sl. 37 gives Ayana Bala by the Sun's northern and southern courses. Neither states a number, a rate or a starting date. The value here comes from two constants in the engine's code and is labelled Lahiri (Chitrapaksha).

How do I convert the decimal result to degrees, minutes and seconds?

Keep the whole part as degrees. Multiply the fraction by 60 and keep the whole part as arcminutes. Multiply what is left by 60 for arcseconds. For 24.227011: 0.227011 × 60 = 13.62, then 0.62 × 60 = 37, so 24°13′37″.

How close is this to a printed Lahiri ayanamsa?

In the nine chart headers from Advanced Predictive Astrology that are legible in the scan, covering births from 1618 to 1993, the engine differs from the printed figure by between 1 and 34 arcseconds. The largest gap is a little over half an arcminute.

Could that small gap change my Moon sign or nakshatra?

Only if the Moon sits within about half an arcminute of a boundary, which by the width arithmetic applies to roughly one position in 3,600 for a sign and one in 1,600 for a nakshatra. The uncertainty in the Moon's own computed position, about 0.1°, is larger than the ayanamsa gap. If your result is close to an edge, the nakshatra calculator is the place to see how close.

Can I switch to the KP, Raman or another ayanamsa?

No. The server exports one ayanamsa function and holds no numeric value for any other system. The sub-lord calculator says explicitly that it is not KP for this reason. A chart cast elsewhere on another system will differ from this one by the same angle on every point.

Why does my Western star sign differ from the sign shown here?

Because the Western sign is tropical and this one is sidereal, and the two are currently a little over 24° apart. Any position in the first 24° or so of a tropical sign falls in the previous sidereal sign; only the last few degrees keep the same name. The Sun sign calculator shows the sidereal result for your date.

Does the ayanamsa affect the tithi or Rahu Kaal?

No. The tithi is the difference between the Moon's and the Sun's longitude, and the same offset is removed from both, so it cancels. Rahu Kaal, Choghadiya and Hora are divisions of the time between sunrise and sunset and do not use the zodiac.

Can I ask for a date far in the past or future?

Yes, any real calendar date in YYYY-MM-DD form is accepted, and the line is simply extended. The further the date lies from 2000, the more the answer rests on the assumption of a constant rate. The comparison with printed values on this page reaches back to 1618; beyond the dates tested there, the figure is an extrapolation and should be treated as one.

Why does the result show so many decimal places?

The server returns the raw result of the arithmetic without rounding. The digits beyond the fourth or fifth place carry no astronomical meaning: the model agrees with published figures to within about half an arcminute, which is the second decimal place of a degree.