Varsha and Masa Bala: Year–Month Lords, Sunrise Boundaries and Full Ledgers

What are Varsha and Masa Bala?

In Astrogyana's parashari-motion-shadbala-2026.2 profile, the calculated year lord receives 15 Virupas of Varsha Bala and the calculated month lord receives 30 Virupas of Masa Bala. These are two terms within Kala Bala. The calculation uses the year and civil month of the local sunrise that anchors the birth's solar day.

Let those inputs be Y and M, with January numbered 1 and December 12. The indices are 3(Y+3) mod 7 for the year and 2(12Y+M+6) mod 7 for the month. They index the sequence Sun, Moon, Mars, Mercury, Jupiter, Venus, Saturn, starting at zero.

This is the specific convention implemented in the application and documented by Maitreya. It is not a universal claim about every school's calendar or annual-chart method. The worked examples use modern Gregorian dates; they are arithmetic exercises, not predictions about a year or month.

Select the sunrise date before extracting the year

First identify sunrise R, the following sunset S, and the next sunrise R₂, such that R ≤ birth < R₂ and R < S < R₂. Only then read Y and M from R's local calendar date. A birth after midnight but before sunrise remains attached to the previous sunrise.

That ordering matters at a month boundary and even more at New Year. A civil birth date of 1 January does not automatically supply January or the new year to these formulas. Before sunrise, the anchoring date can still be 31 December, with its previous year and month.

The Kundli builder converts solar events into the birth location's time zone. Keep that local context while retaining absolute timestamps for comparisons. Reading the year from a UTC representation can produce a different answer near midnight, even though the represented sunrise instant has not changed.

Use the correct seven-planet lookup

The remainder is an index, not a weekday and not a house number. Remainder 0 is Sun, not an empty result. Remainder 6 is Saturn. A program using one-based indexing must adjust explicitly; inserting a dummy first entry without changing the formula can shift every assignment.

This lookup differs from the repeating planetary-hour sequence beginning Saturn, Jupiter, Mars. The year and month formulas already encode their own cyclic steps. Replacing the lookup with the hora order changes the convention rather than simplifying it.

Calculate the year lord with the full integer

For Y=2026, add three to obtain 2029, multiply by three to obtain 6087, and divide by seven. Since 6087=7×869+4, the remainder is 4: Jupiter. The value 6087 is an intermediate integer, not a strength score. Only the selected lord receives 15 Virupas.

Increasing Y by one increases the index by three modulo seven. After seven years the intermediate integer has increased by 21, so the remainder returns to the same value. Every planet appears once in this seven-year cycle because repeated steps of three visit all seven remainders.

Do not replace the year lord with the weekday of 1 January. That would be a different algorithm involving the calendar's day-of-week cycle. The displayed table follows the stated integer formula; it does not count elapsed weekdays or infer a planet from the year's first civil day.

Calculate the month lord without dropping the year

For an October 2026 anchor, calculate 12×2026+10+6=24328. Doubling gives 48656=7×6950+6. The month lord is therefore Saturn and receives 30 Virupas. The year is part of the month formula; October is not permanently assigned to one planet in every year.

Within a year, advancing one month adds two modulo seven. Advancing to the same month next year adds 24, equivalent to three modulo seven. Advancing from December to the next January still adds only two, because the year increment and month reset combine into one step of the underlying month count.

A programming API may number January as zero. Convert it to M=1 before using this formula. Omitting that conversion shifts the month index by two. Similarly, passing a lunar month number or a different calendar's year without conversion changes the input system.

Month, year and leap-day boundaries

For these synthetic schedules, every local sunrise is 06:00 and sunset is 18:00 at a fixed +05:30 offset. Complete neighbouring dates are supplied so that each solar cycle is valid. The table does not report any city's actual sunrise times.

At 1 November 05:59:59, the October anchor still gives Saturn as month lord. At 06:00, November's Moon assignment starts. At New Year, the old year and December remain together until the new sunrise: changing only the month at midnight would combine inputs from different anchor dates.

Leap day adds a real civil date and another sunrise cycle, but it does not add a thirteenth month. On 29 February 2028, M remains 2. Before 1 March sunrise, the anchor is still 29 February; afterward M becomes 3. Leap years matter when locating valid consecutive dates, while the two formulas continue to use ordinary Y and M.

Audit separate and shared lord allocations

For an October 2026 sunrise day, Jupiter receives the year term and Saturn receives the month term. For a September 2026 sunrise day, Jupiter holds both roles. Keep separate columns so that a shared lord does not cause one term to overwrite the other.

Each ledger allocates 15+30=45 Virupas across the seven planets, equal to 0.75 Rupas. One planet can receive all 45, but the total cannot become 90 by treating the terms as two copies of the combined amount. A zero here means neither of these two roles belongs to that planet; other strength components can still be nonzero.

The calculation does not accumulate 15 per completed year or 30 per elapsed month. These numbers are the current chart's allocations. The year index selects a recipient, while the month index selects another recipient that may be the same planet.

Three consistency checks that expose mistakes

First, use periodicity: the same civil month seven years later must have the same two lords under these formulas, because the year expression changes by 21 and the month expression by 168, both divisible by seven. This statement concerns the formula inputs, not identical real sunrise instants or an identical whole chart.

Second, check consecutive months including December to January. The month-lord index must advance by two modulo seven each time. A December reset that produces a large discontinuity usually indicates that the year was not updated together with the month.

Third, add the ledger columns. Exactly one year allocation of 15 and one month allocation of 30 should appear. Their recipients can coincide, so the number of nonzero planet rows can be one or two. Requiring two different recipients would incorrectly reject valid shared-lord cases such as September 2026.

Keep local calendar labels and absolute time distinct

Imagine a separate New Year fixture with sunrise at 05:00 on 1 January 2027 at +05:30. That instant is 23:30 UTC on 31 December 2026. The local anchor supplies Y=2027 and M=1, giving Sun and Venus, even though its UTC representation carries the previous civil year.

Changing only how a birth instant is displayed must not change its physical position relative to the solar events. But stripping the events' local context before reading their dates can change Y and M. These are different operations: compare instants on a consistent time scale, and read calendar fields in the intended local zone.

The examples deliberately keep their offset fixed. Where an offset changes, event timestamps must encode the correct offset for each instant. The calendar logic also requires consecutive local sunrise dates; a gap in supplied events should not be bridged as if it were an ordinary one-day cycle.

Do not mix year–month strength with other calendar methods

The word Varsha can occur in discussions of annual charts, but this guide does not calculate a solar return, Muntha or an annual-chart ruler. Its fifteen-point contribution is one item in a natal strength calculation. A report headed “year lord” needs its method identified before it can be compared with another report.

Likewise, the civil month in this profile is not the lunar month named in a festival calendar. Read the Amanta and Purnimanta guide for that separate question. Knowing that two systems use the word month is not enough to transfer their inputs or conclusions.

Missing solar events and uncertain birth ranges

The existing implementation needs a valid sunrise–sunset–next-sunrise cycle. It filters incomplete daily records before selecting the pair of consecutive sunrise dates. If it cannot build a valid context, Shadbala is unavailable. It does not replace that state with seven rows of zero year and month strength.

A birth range from 05:58 to 06:02 on 1 January in the main fixture crosses the anchor transition. Both the year and month recipients can change. Report the two candidate ledgers and the reason for the ambiguity. Averaging them creates a new weighting scheme that is not part of the stated discrete rule.

These formulas and examples are scoped to modern positive Gregorian years as used here. Historical calendar conversion, era-year labels and unusual date systems need explicit handling before arithmetic is attempted. A correct remainder cannot rescue an incorrectly interpreted date.

A compact calculation record to retain

1. Write the location, birth instant and resolved time zone.
2. Record the valid solar cycle and the local date of its anchoring sunrise.
3. Extract Y and the one-based civil month M from that anchor.
4. Save both intermediate integers and their remainders.
5. Look up the planets in Sun-to-Saturn order.
6. Assign 15 and 30 separately and check the 45-Virupa total.
7. Combine these terms with the remaining strength components only afterward.

The Dina and Hora Bala guide adds the weekday and current-hour contributions. The unit and ratio guide explains how to read totals, while the Yuddha Bala ledger explains a later temporal-strength redistribution. These connections make a calculation auditable without treating any isolated subtotal as a complete judgment of a person.

Frequently asked questions