How Hastro computes the Hindu calendar
Every tithi, festival and muhurat on Hastro is computed from the positions of the Sun and Moon at your own sunrise, not copied from a printed panchang. This is why the same festival can fall on different dates in Varanasi and London, and how the engine handles skipped tithis, extra months and disagreeing traditions.
The day begins at sunrise, and sunrise depends on where you are
A Hindu calendar day is not midnight to midnight. It runs from one sunrise to the next, and the tithi, nakshatra and other elements that name the day are the ones in force at that sunrise. Sunrise in Varanasi and sunrise in London are hours apart, and in that gap the Moon keeps moving. If a tithi ends at 06:30 in India, it is still running at sunrise in Varanasi but already over at sunrise in London, where the local time is only 02:00. The two cities then name the same civil date after different tithis, and a festival that is fixed to a tithi lands on different dates.
Most calendar apps avoid this by computing everything for one reference city and shifting the clock. Hastro computes sunrise for the coordinates you give it and reads the sky at that instant. That is the whole idea of the site, and everything below follows from it.
What is computed, and from what
The engine starts from the apparent geocentric longitudes of the Sun and the Moon. The Sun comes from VSOP87, the Moon from Meeus’ lunar theory, both in pure Rust with no data files. Their accuracy is about 1 arcsecond for the Sun and 10 arcseconds for the Moon. The Moon moves about half an arcsecond per second of time, so a 10 arcsecond error moves a tithi boundary by around 20 seconds. Printed panchangs round to the minute.
From those two longitudes come the five limbs of the panchang: tithi from the difference of the two, nakshatra and yoga from the Moon and the sum, karana as half a tithi, and vaar from sunrise. Each transition is found by bisection to the second. A day carries the elements at sunrise and every change until the next sunrise, so a page for one date can show two tithis or none ending.
Sidereal positions need an ayanamsa, the offset between the tropical and sidereal zodiacs. It grows by about 50 arcseconds a year, so it is applied at the instant of each computation rather than once for the year. Lahiri is the default; Raman and Krishnamurti are available.
Skipped and repeated tithis
A tithi is the time the Moon takes to gain twelve degrees on the Sun. Because the Moon’s speed varies, a tithi lasts anywhere from about 20 to 26 hours. When a short tithi begins after one sunrise and ends before the next, no day is named after it: a kshaya, or lost, tithi. When a long tithi covers two sunrises, two days carry its name: a vriddhi tithi. Both happen several times a year and are the usual reason two printed panchangs disagree on a fasting day. The engine reports them as flags on the day rather than silently picking one.
Months, and the extra month
A lunar month is either amanta, ending at the new moon, or purnimanta, ending at the full moon, and different regions use different conventions. The same festival is described with two different month names in the north and the south. Hastro computes both and lets each city default to its regional convention.
Twelve lunar months fall eleven days short of the solar year, so about every 32 months an extra month is inserted. The rule is astronomical: a lunar month during which the Sun enters no new sign is declared adhik. The engine finds these by locating the sankrantis and the new moons and checking which intervals contain none. Very rarely a month contains two sankrantis and is dropped instead.
Festivals and muhurat as rules, not tables
A festival on Hastro is not a stored date. It is a rule such as “Kartika, krishna paksha, tithi 30, decided by the tithi at moonrise or at sunrise” with policies for what to do in an adhik month and when the tithi repeats. The rules live in versioned data files, 72 festivals so far, and each result carries the versions of the engine and the rules that produced it. When a rule changes, every past result can be reproduced.
Muhurat search works the same way. For each daytime window, split wherever the tithi or nakshatra changes, the engine adds the weights of favourable elements and subtracts the inauspicious periods such as Rahu kaal, Bhadra and Panchak, and reports the reasons for the score. When birth details are given, tara bala and chandra bala are checked against the birth nakshatra and Moon sign. The scoring is meant to be transparent, so a user can see why a window scored 72 and decide for themselves.
How it is checked
The engine has no clock, no network and no database, so every computation is repeatable. Rows filled by hand from government holiday lists form a golden test set. Full-year snapshots for seven cities on three continents catch any change to the second. Property tests throw random dates between 1900 and 2100 and random places at the engine and require a typed error or a result, never a crash. Regional conventions are still being reviewed, and reports of a wrong date from the app are read and, when a rule needs changing, fixed in the rule data.
FAQ
Why does Hastro show a different date from my printed panchang?
The usual reasons are a different city, a different sunrise definition, a different month convention, or a tithi that ends within minutes of sunrise. Set your own city, then compare the tithi end time shown with the one in the panchang.
Which sunrise does Hastro use?
By default the upper limb of the Sun with refraction, as in civil almanacs. The centre of the Sun without refraction, which some panchangs use, is available in the settings.
Is the calendar accurate far from India?
Yes, within the latitudes where the Sun rises and sets every day. Near the poles some days have no sunrise or no moonrise, and the engine reports that rather than guessing.
Can I see the rules a festival uses?
The reasons for every muhurat score are shown on the page. Festival rules are stored as versioned data and their version is printed with every result.